{"id":"xN-3rdMR9GM","title":"NDNA Issue 1- UX, DX, and Building With Privacy in Mind","description":"In this episode of NDNA, we dive deep into what real product-focused UX looks like in crypto—through the lens of two new NEAR ecosystem releases: Intear Wallet and SurgeSwap. These aren’t flashy protocol demos—they’re quiet UX revolutions that hide the blockchain, not showcase it.\n\nWe also discuss the Roman Storm / Tornado Cash trial, what it means for the future of privacy infrastructure, and why developers need to rethink privacy as a design philosophy, not a feature.\n\nPlus, we challenge the NEAR developer community:\n • Are our SDKs empowering new types of products, or just speeding up the same old builds?\n • How should privacy standards be baked into developer tools by default?\n\nIf you’re building in Web3 or just care about data ownership, this episode is for you.\n\n👉 Subscribe for more dev-first analysis on Web3, NEAR Protocol, and building the next internet.","channel_name":"NEAR DevHub","published_at":"2025-07-18T00:00:00.000Z","thumbnail_url":"https://img.youtube.com/vi/xN-3rdMR9GM/hqdefault.jpg","transcript_text":"Hello. It's July 18th, 2025, and this is nDNA. This issue, the quiet reflection, UX as a product philosophy. If you've been watching social media feedback related to NEAR, IntearWallet and SurgeSwap are receiving the kind of attention that few products in the space typically manage. What sets them apart? It's not that they're waving a flag of technical novelty. It's that they're designed to feel normal, a version of invisible UX. So what are these products? IntearWallet is a open-source wallet for the NEAR ecosystem. It offers fast load times, subaccount creation, staking countdowns, and privacy-friendly features like caching tokens and NFT images locally instead of relying on third-party servers. It feels modern, secure, and focused on making the wallet experience seamless. SurgeSwap is in alpha stage, cross-chain swap interface powered by NEAR Intense, and it allows users to swap assets across multiple blockchains, including things like Solana, uh, Base, Bitcoin, with a single click without needing to navigate complex bridging or numerous wallets. It abstracts the way the chain entirely from the user experience and puts the whole process into a couple clicks. For too long, crypto products have tried to educate users into understanding blockchain before offering value. This is backwards. Users don't need to know the inner workings of TCIP to use the internet, and they shouldn't need to understand NEAR Protocol to stake tokens and swap assets or even manage accounts. IntearWallet doesn't just load fast, it hides complexity with thoughtful defaults. For example, the subaccount creation that can leverage NEAR's unique account model without forcing a user to learn wh- how it works. Smart caching of tokens and NFT images that isn't just improving speed, but it's also enhancing privacy. Whereas, like IntearWallet, let's you swap assets across chains not knowing what chains have to exist and what's going on underneath the hood. Both products reject the old Web3.0 mistake of UX as an afterthought to the protocol design. Instead, they're asking, what is the job the user's hiring this product to do? Then they design from that outcome backwards. This is the narrative we need to push in the NEAR ecosystem. Product first, protocol subordinate. Protocols are tools to enable outcomes, not the product itself. The real innovation is in the product experience, not flaunting technological sophistication. If NEAR can set a precedent here, it positions itself as the blockchain for real users, not just developers building for other developers. But we have to watch, will these UX philosophies become the NEAR norm or Interand and SurgeSwap outliers right now? We should want NEAR to be the place where the default is the invisible UX, or better said, where the car ride isn't explained to the passenger, they just arrive faster and safer. Developing tooling, the real purpose is empowerment, not speed. Tooling-related conversations in crypto often focus on speed. How quickly can you get from an idea to MVP? But there's a deeper question that we should be asking. Can these tools enable developers to create new kinds of products that weren't feasible before? Let's be clear. Better SDKs, different language options, and tooling aren't just about reducing time to deploy, they're about expanding the space of what's possible. NEAR's SDKs in Go, Swift, Rust, JSTS, uh, Python, and more aren't just check marks as a DevRel roadmap, they're invitations to cross-pollinate with established developer cultures. For example, backend developers can now integrate NEAR smart contracts with their existing cloud native infrastructures without needing to learn Rust or Solidity. Instead, they can just use Go or Python. This matters because products today are hybrid. Centralized infrastructure, decentralized assets, user-owned data, all stitched together. Great tooling is the only way to make that hybrid model not just viable but pleasant to build. The real test for NEAR tooling is, does it lower the barrier for new devs coming from non-blockchain backgrounds? Does it enable the creation of primitives that Web2.0 frameworks can't easily support? We should be demanding more SDKs that integrate directly into Web2.0 dominant frameworks like React Native or Flutter, not because we're trying to Web2.0-ify the Web3.0, but because these frameworks own developer mindshare. We need to rethink what it means to be a protocol. If NEAR can plug directly into those, it ceases to be an separate ecosystem, it becomes part of the developer's default toolkit. The insight here is that great tooling is a form of empowerment, so it transforms the ambitious into the achievable. NEAR needs to ensure that it's not just serving crypto-native developers, but inviting the full spectrum of builders to create what was previously impractical. Privacy, Roman Storm, and data ownership, a design not a feature. The Roman Storm case has become one of the most significant legal battles in crypto history, not for what it means just for one developer, but what it signals about the future of privacy infrastructure. Storm, one of the developers behind Tornado Cash, is being prosecuted for his role in building the tool that enabled private, untraceable transactions on Ethereum. This trial is a collision between open-source development, user privacy rights, and state control over financial networks.We talked about privacy and data ownership in issue 0, but Roman Storm's trial sharpens the stakes. Tornado Cash was a tool designed with privacy at its core, but as a standalone, isolated protocol, it became an easy regulatory target. The Roman Storm case is more than just a legal trial, it's a referendum on how privacy infrastructure is treated when it challenges the surveillance status quo. This isn't just about whether Storm knowingly facilitated money laundering. The underlying question regulators are really asking is should privacy be permissioned? One of the most telling quotes from the trial coverage sums it up, \"If code is speech, then writing a privacy tool is now treated as yelling 'fire' in a crowded theater, dangerous, suspect, and potentially criminal.\" If that's the standard, then privacy itself is framed as inherently dangerous, not a human right or a feature. That is and will continue to be the battleground on which privacy-focused developers are building. Storm's case forces us to rethink how we build privacy. Integrated privacy. Privacy should be indistinguishable from the product's core functionality. It should be the default behavior, not a separate optional module. Privacy should not adjust based on user context. For example, while it should obscure transaction metadata, unless a user opts to reveal it in a compliance context. NEAR's tooling should make the privacy path of least resistance. Standard libraries should encrypt sensitive data by default, provide local first data models, include selective disclosure tools. However, let's be clear, most developers lack expertise in implementing privacy effectively. It's not just about encrypting data or adding 0 knowledge proofs, it's about providing defaults that make privacy automatic, not opt-in. It's not about degrading the user experience, where the user's more likely to opt for the better performing non-privacy focused option. How should privacy be standardized in developer tools? SDKs should automatically encrypt user data at rest and in transit without developers needing to configure it manually. Tools should prioritize storing data locally on the user's device with clear APIs for syncing or sharing data selectively. SDKs should include patterns for sharing proofs of data without revealing the data itself, for example, a ZK proof or verifiable credentials. Provide built-in analytics that strip identiful- identifiable information so devs can track usage without violating user privacy. Standard UI elements that inform users when data's being collected, shared or used, transparency by default. When privacy is a framework and not a feature, it changes the developer experience entirely. It becomes harder to build something invasive accidentally. Instead, the path of least resistance is to create products that respect and protect the user. The insight here is that privacy isn't just for ideologues, it's a competitive advantage. Users will flock to tools that respect their data without making them work for it. While Roman's freedom is indeed on the line, and the stakes for all developers who care about privacy are potentially enormous, Roman Storm's trial is less about the individual guilt and more about setting a precedent. Can developers build privacy tools without legal risk? NEAR has a chance to answer that question by embedding privacy at the protocol, tooling, and the UX levels by simply making it the way that things are built. If we get this right, NEAR doesn't just ship more products, it redefines what building in Web3 feels like, fast, flexible, priva- private by design and focused on the user, not the protocol. This is the work that will define NEAR's position in the broader tech landscape. It's not just another chain, it's potentially the first product ecosystem in Web3 that feels like the real internet. Please make sure to subscribe and share if you found this insightful. And we will see you again next week on NDNA.","transcript_synced_at":"2026-11-03T03:51:19.699Z","segments":[{"start_seconds":5,"text":"Hello. It's July 18th, 2025, and this is nDNA. This issue, the quiet reflection, UX as a product philosophy.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=5s"},{"start_seconds":14,"text":"If you've been watching social media feedback related to NEAR, IntearWallet and SurgeSwap are receiving the kind of attention that few products in the space typically manage.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=14s"},{"start_seconds":23,"text":"What sets them apart? It's not that they're waving a flag of technical novelty. It's that they're designed to feel normal, a version of invisible UX.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=23s"},{"start_seconds":34,"text":"So what are these products? IntearWallet is a open-source wallet for the NEAR ecosystem.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=34s"},{"start_seconds":40,"text":"It offers fast load times, subaccount creation, staking countdowns, and privacy-friendly features like caching tokens and NFT images locally instead of relying on third-party servers.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=40s"},{"start_seconds":52,"text":"It feels modern, secure, and focused on making the wallet experience seamless.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=52s"},{"start_seconds":58,"text":"SurgeSwap is in alpha stage, cross-chain swap interface powered by NEAR Intense, and it allows users to swap assets across multiple blockchains, including things like Solana, uh, Base, Bitcoin, with a single click without needing to navigate complex bridging or numerous wallets.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=58s"},{"start_seconds":79,"text":"It abstracts the way the chain entirely from the user experience and puts the whole process into a couple clicks.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=79s"},{"start_seconds":86,"text":"For too long, crypto products have tried to educate users into understanding blockchain before offering value. This is backwards.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=86s"},{"start_seconds":94,"text":"Users don't need to know the inner workings of TCIP to use the internet, and they shouldn't need to understand NEAR Protocol to stake tokens and swap assets or even manage accounts.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=94s"},{"start_seconds":106,"text":"IntearWallet doesn't just load fast, it hides complexity with thoughtful defaults.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=106s"},{"start_seconds":112,"text":"For example, the subaccount creation that can leverage NEAR's unique account model without forcing a user to learn wh- how it works.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=112s"},{"start_seconds":120,"text":"Smart caching of tokens and NFT images that isn't just improving speed, but it's also enhancing privacy.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=120s"},{"start_seconds":127,"text":"Whereas, like IntearWallet, let's you swap assets across chains not knowing what chains have to exist and what's going on underneath the hood.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=127s"},{"start_seconds":136,"text":"Both products reject the old Web3.0 mistake of UX as an afterthought to the protocol design.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=136s"},{"start_seconds":144,"text":"Instead, they're asking, what is the job the user's hiring this product to do? Then they design from that outcome backwards.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=144s"},{"start_seconds":153,"text":"This is the narrative we need to push in the NEAR ecosystem. Product first, protocol subordinate.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=153s"},{"start_seconds":160,"text":"Protocols are tools to enable outcomes, not the product itself. The real innovation is in the product experience, not flaunting technological sophistication.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=160s"},{"start_seconds":171,"text":"If NEAR can set a precedent here, it positions itself as the blockchain for real users, not just developers building for other developers.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=171s"},{"start_seconds":180,"text":"But we have to watch, will these UX philosophies become the NEAR norm or Interand and SurgeSwap outliers right now?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=180s"},{"start_seconds":190,"text":"We should want NEAR to be the place where the default is the invisible UX, or better said, where the car ride isn't explained to the passenger, they just arrive faster and safer.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=190s"},{"start_seconds":207,"text":"Developing tooling, the real purpose is empowerment, not speed. Tooling-related conversations in crypto often focus on speed.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=207s"},{"start_seconds":216,"text":"How quickly can you get from an idea to MVP? But there's a deeper question that we should be asking.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=216s"},{"start_seconds":223,"text":"Can these tools enable developers to create new kinds of products that weren't feasible before? Let's be clear.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=223s"},{"start_seconds":231,"text":"Better SDKs, different language options, and tooling aren't just about reducing time to deploy, they're about expanding the space of what's possible.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=231s"},{"start_seconds":240,"text":"NEAR's SDKs in Go, Swift, Rust, JSTS, uh, Python, and more aren't just check marks as a DevRel roadmap, they're invitations to cross-pollinate with established developer cultures.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=240s"},{"start_seconds":254,"text":"For example, backend developers can now integrate NEAR smart contracts with their existing cloud native infrastructures without needing to learn Rust or Solidity.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=254s"},{"start_seconds":263,"text":"Instead, they can just use Go or Python. This matters because products today are hybrid.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=263s"},{"start_seconds":270,"text":"Centralized infrastructure, decentralized assets, user-owned data, all stitched together.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=270s"},{"start_seconds":277,"text":"Great tooling is the only way to make that hybrid model not just viable but pleasant to build.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=277s"},{"start_seconds":283,"text":"The real test for NEAR tooling is, does it lower the barrier for new devs coming from non-blockchain backgrounds?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=283s"},{"start_seconds":290,"text":"Does it enable the creation of primitives that Web2.0 frameworks can't easily support?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=290s"},{"start_seconds":296,"text":"We should be demanding more SDKs that integrate directly into Web2.0 dominant frameworks like React Native or Flutter, not because we're trying to Web2.0-ify the Web3.0, but because these frameworks own developer mindshare.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=296s"},{"start_seconds":309,"text":"We need to rethink what it means to be a protocol. If NEAR can plug directly into those, it ceases to be an separate ecosystem, it becomes part of the developer's default toolkit.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=309s"},{"start_seconds":321,"text":"The insight here is that great tooling is a form of empowerment, so it transforms the ambitious into the achievable.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=321s"},{"start_seconds":328,"text":"NEAR needs to ensure that it's not just serving crypto-native developers, but inviting the full spectrum of builders to create what was previously impractical.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=328s"},{"start_seconds":338,"text":"Privacy, Roman Storm, and data ownership, a design not a feature.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=338s"},{"start_seconds":344,"text":"The Roman Storm case has become one of the most significant legal battles in crypto history, not for what it means just for one developer, but what it signals about the future of privacy infrastructure.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=344s"},{"start_seconds":354,"text":"Storm, one of the developers behind Tornado Cash, is being prosecuted for his role in building the tool that enabled private, untraceable transactions on Ethereum.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=354s"},{"start_seconds":363,"text":"This trial is a collision between open-source development, user privacy rights, and state control over financial networks.We talked about privacy and data ownership in issue 0, but Roman Storm's trial sharpens the stakes.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=363s"},{"start_seconds":378,"text":"Tornado Cash was a tool designed with privacy at its core, but as a standalone, isolated protocol, it became an easy regulatory target.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=378s"},{"start_seconds":388,"text":"The Roman Storm case is more than just a legal trial, it's a referendum on how privacy infrastructure is treated when it challenges the surveillance status quo.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=388s"},{"start_seconds":397,"text":"This isn't just about whether Storm knowingly facilitated money laundering. The underlying question regulators are really asking is should privacy be permissioned?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=397s"},{"start_seconds":407,"text":"One of the most telling quotes from the trial coverage sums it up, \"If code is speech, then writing a privacy tool is now treated as yelling 'fire' in a crowded theater, dangerous, suspect, and potentially criminal.\"","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=407s"},{"start_seconds":420,"text":"If that's the standard, then privacy itself is framed as inherently dangerous, not a human right or a feature.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=420s"},{"start_seconds":426,"text":"That is and will continue to be the battleground on which privacy-focused developers are building. Storm's case forces us to rethink how we build privacy.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=426s"},{"start_seconds":435,"text":"Integrated privacy. Privacy should be indistinguishable from the product's core functionality.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=435s"},{"start_seconds":441,"text":"It should be the default behavior, not a separate optional module. Privacy should not adjust based on user context.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=441s"},{"start_seconds":449,"text":"For example, while it should obscure transaction metadata, unless a user opts to reveal it in a compliance context.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=449s"},{"start_seconds":457,"text":"NEAR's tooling should make the privacy path of least resistance. Standard libraries should encrypt sensitive data by default, provide local first data models, include selective disclosure tools.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=457s"},{"start_seconds":468,"text":"However, let's be clear, most developers lack expertise in implementing privacy effectively.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=468s"},{"start_seconds":474,"text":"It's not just about encrypting data or adding 0 knowledge proofs, it's about providing defaults that make privacy automatic, not opt-in.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=474s"},{"start_seconds":482,"text":"It's not about degrading the user experience, where the user's more likely to opt for the better performing non-privacy focused option.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=482s"},{"start_seconds":491,"text":"How should privacy be standardized in developer tools?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=491s"},{"start_seconds":496,"text":"SDKs should automatically encrypt user data at rest and in transit without developers needing to configure it manually.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=496s"},{"start_seconds":506,"text":"Tools should prioritize storing data locally on the user's device with clear APIs for syncing or sharing data selectively.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=506s"},{"start_seconds":515,"text":"SDKs should include patterns for sharing proofs of data without revealing the data itself, for example, a ZK proof or verifiable credentials.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=515s"},{"start_seconds":526,"text":"Provide built-in analytics that strip identiful- identifiable information so devs can track usage without violating user privacy.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=526s"},{"start_seconds":535,"text":"Standard UI elements that inform users when data's being collected, shared or used, transparency by default.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=535s"},{"start_seconds":544,"text":"When privacy is a framework and not a feature, it changes the developer experience entirely. It becomes harder to build something invasive accidentally.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=544s"},{"start_seconds":554,"text":"Instead, the path of least resistance is to create products that respect and protect the user.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=554s"},{"start_seconds":561,"text":"The insight here is that privacy isn't just for ideologues, it's a competitive advantage. Users will flock to tools that respect their data without making them work for it.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=561s"},{"start_seconds":572,"text":"While Roman's freedom is indeed on the line, and the stakes for all developers who care about privacy are potentially enormous, Roman Storm's trial is less about the individual guilt and more about setting a precedent.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=572s"},{"start_seconds":584,"text":"Can developers build privacy tools without legal risk?","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=584s"},{"start_seconds":588,"text":"NEAR has a chance to answer that question by embedding privacy at the protocol, tooling, and the UX levels by simply making it the way that things are built.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=588s"},{"start_seconds":598,"text":"If we get this right, NEAR doesn't just ship more products, it redefines what building in Web3 feels like, fast, flexible, priva- private by design and focused on the user, not the protocol.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=598s"},{"start_seconds":611,"text":"This is the work that will define NEAR's position in the broader tech landscape. It's not just another chain, it's potentially the first product ecosystem in Web3 that feels like the real internet.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=611s"},{"start_seconds":623,"text":"Please make sure to subscribe and share if you found this insightful. And we will see you again next week on NDNA.","url":"https://www.youtube.com/watch?v=xN-3rdMR9GM&t=623s"}],"youtube_url":"https://youtube.com/watch?v=xN-3rdMR9GM","url":"https://near-pedia.xyz/videos/xN-3rdMR9GM"}