# =nil; Foundation | Enshrined Tokens: Infinite-Scale Native Interop - Dennis O. Huisman | ETHDam III - Channel: [CryptoCanal](https://streameth.org/cryptocanal) - Date: 2025-10-07 - Duration: 13:00 - Watch: https://streameth.org/watch/yt-qZFr0GvHIoc - YouTube: https://www.youtube.com/watch?v=qZFr0GvHIoc ## Description Welcome to the 3rd Edition of ETHDam, hosted May 9–11, 2025 in Amsterdam. This year, we brought together the brightest minds in privacy, security, and AI for a unique 48-hour hackathon + conference combo. 🌷 https://www.ethdam.com// 🌷 ------------------ =nil; Foundation | Enshrined Tokens: Infinite-Scale Native Interop - Dennis Oliver Huisman | ETHDam III - 2025 𝕏 Follow: https://x.com/Xidea404 https://nil.foundation/ https://x.com/nil_foundation ------------------ About ETHDam & CryptoCanal ETHDam is powered by CryptoCanal, an education and events platform rooted in Amsterdam, expanding into Rotterdam and ZΓΌrich. Keep up with us to see updates on future events: https://www.cryptocanal.org/ Follow CryptoCanal on X: https://twitter.com/CryptoCanal Join CryptoCanal TG Community: https://t.me/CryptoCanalCommunity Join CryptoCanal Discord: https://discord.com/invite/XJVjpCqQBz CryptoCanal unites crypto enthusiasts committed to making a positive impact. Unapologetically political, we prioritize education, events, and services while championing cypherpunk values like privacy, sovereignty, and censorship resistance. ------------------ πŸŽ₯ Credits: Intro / outro by babyPRO - https://babypro.art/ ETHDam Photography by Paulus – https://concretestate.eu/ MC of ETHDam - Laura Brown - Cofounder at JobStash & Veri, and your resident crypto ginger. https://linktr.ee/laurabxyz ------------------ Special thanks to our partners who made ETHDam possible: 🌹 Hackathon – Bouquet: Oasis Network https://oasisprotocol.org/ 🌷 Hackathon – Petal: Circles https://aboutcircles.com πŸ’› Conference – Gold: Zano https://zano.org/ Dash https://www.dash.org/ Bitvavo https://bitvavo.com/en 🩢 Conference – Silver: Igra Labs https://igralabs.com/hero πŸ’› Conference – Copper: Lido https://lido.fi/ DeTrip https://detrip.travel/ Cake Wallet https://cakewallet.com/ The Grid https://thegrid.id/ Calimero Network https://calimero.network/ 0xbow https://0xbow.io/ Mina https://minaprotocol.com/ JobStash https://jobstash.xyz/ Cyber Capital https://www.cyber.capital/ POAP https://poap.xyz/ Acronym Foundation (Supported our Top 10 Hackers) https://acronymfoundation.org/ 🌱 Sponsor: EF Ecosystem Support Program https://esp.ethereum.foundation ------------------ 0:00 | Introduction 0:48 | What Are Enshrined Tokens? 1:36 | Talk Agenda Overview 2:07 | What Is Sharding? 3:44 | Sharding Challenges 5:32 | Layer 2 Sharding & ZK Proofs 6:35 | ERC-20 Limitations in Shards 8:02 | =nil's Token Architecture 9:23 | Scaling DEXs with Shards 10:26 | Audience Q&A ## Transcript Welcome to East to E to E to East to East. Hello. Hello. Hello. Uh morning. Um I'm Laura from Job Stash. I'm going to be sort of guiding us through this morning. Um we've got a few really good speakers um throughout the morning. Um just a few things. We the talks are around 15 minutes. If we have time, we'll try and open it up to Q&A. Um if not then the speakers usually stick around for a few minutes outside after. So feel free to go up to them and have a chat to them after. Um so please welcome to the stage Dennis to speak about enshrined tokens on Ethereum. So hello everybody. Um good morning to this uh start of the day presentation on uh what we're working on. Um let's get to it. Um yeah, so I think uh well actually this slide is supposed to be somewhere else. Um enshrined tokens. Uh what does this mean? Uh what does this mean in this context? Some of you might know Neil has been working on uh a coming uh ZK rollup uh with sharding. we called ZK sharding for uh Ethereum. Um and that's something I want to dig in further today and in particular around our um our token design. Uh so this this is like the meat of it, but uh let's save the best thing for last. We'll get to it later. Um yeah, our agenda I think uh it it would be helpful to understand first about the scaling of roll-ups uh um fundamental knowledge about sharded decentralized systems. These are the goals of what I' I'd like to uh touch upon today. Um from a high level because I just have 15 minutes. Um I want to run through uh what sharding means uh in general rollup sharding uh and our token design and then uh a little practical example of how we've done that with DAPs. Um as much as I can squeeze in into this time frame actually. So yeah, what is sharding? Um some of you might know it from uh traditional database systems. um it enables us to scale uh throughput in databases by uh just splitting it by uh some uh granular level. So in the typical case we split it by uh on the user level. So um then we have two different uh sets of the database uh and they handle different loads for the different user subsets. Uh sometimes it's by geography etc etc. Uh but this enables us to uh just remain performant at a larger scale. So how does that look like for a network? Uh very similar actually. Uh Ethereum has a an account model. So um it it's uh uh we do it on an account level. So uh every shard you can see as its own subnet network and that's actually what it is. It has its own validator set and its own consensus and um it uh it communate it communicates across shards with uh with asyncoms. So that's something that's uh handled by the core core program uh that allows you to send a message to some other shard. Uh but that's executed at a later block. I think that's a little bit like on a high level how this looks like. Um every shard has its own gas uh model and its own gas pricing mechanism. So um it can very well be that the gas prices are just very different in one shard than the other um depending on usage. They they always depend on usage. They all have the same gas mechanism. It's just like one will be more expensive than the other just based on usage. That's what I mean. Um so what problems do we want to solve? Uh well exactly scaling. Uh we want to avoid there being uh just a single pool on unis swap that uh uh dictates the price for the whole chain. Um we we very much like to avoid that. So um in fact we want uh uh to to give developers this flexibility to choose uh what components of their application they'd like to uh possibly uh have uh very high levels of uh um activity uh without it influencing the rest of their app. So uh we want to contribute to the decentralization of roll-ups um application scaling and of course uh utilization efficiency. These are all things that come together with with sharding. Uh but why sharding? Um uh well uh because uh by doing this you're able to um uh at will uh uh choose uh a level of scale that you need at the point in time and that's actually how we're going to organize the protocol too. Um we're going to uh be able to say at will how many shards we want to add to the system based on the usage there is. So uh layer two sharding. Yeah, I touched upon this before. Um we use uh yeah each chart is you can see it as its own subn network. Um what is a little bit not uh yeah we touched about it we touched it here a little bit with the zk proof and validity proof data commitment. Um there are uh a zk proofs for every state transition in every shard. Um, and that's uh uh that's in order to uh um match higher uh security guarantees that Ethereum is able to offer because of its degree of decentralization which we don't expect to have uh at the uh start uh stages of of mainet. Uh we're on test net right now by the way. So, okay, great. So, this brings me to ERC20. I I can see I'm still on time here. So, uh some of you might know it. Um I think it in a um summarized is actually this uh this image does it very well. Um it's uh a single it's a single program running on uh that that holds the state for the balances for all uh accounts that hold the token. So uh this program will uh update uh who owns what whenever a transaction is sent to the Ethereum network. So if I send a Pep Pepecoin to uh to uh my friend Vlad, then Vlad is going to get the Pepp Pepcoin, but this contract will have to update uh the address with the Pepcoin I had to Vlad's address after the end of the transaction. So um it all happens in this one place. That's uh that's the gist of ERC20. Um and uh that's exactly what happens. So uh that's what we see here. Um I think it all goes through through the one contract. everything is saved in this one particular uh uh space um of storage. So why can't this work in sharding? It's because it will require an as call for uh calling this one contract in this one shard for wherever you are else you are uh on the network. Especially if you're like in a multi-sharted uh setup like I I ran through before, you're going to have to wait at least two blocks in advance until uh you know what happened with the with the uh or you know what what the outcome is of your uh Pepid coin transaction. So it's not it doesn't really uh it kind of defeats the purpose of trying to scale the chain with with sharding. uh uh if you have this degree of centralization in the end, you might as well not have done the sharding um because uh well yeah um you'd want it to to happen individually and in parallel in any any in every shard. So what do we need? Um we need an ability to create new tokens uh owner control and supply management. we actually need need all the uh functionalities of it um uh without having uh uh the need to call a single shard. So um luckily on nil accounts are all uh smart contracts. So um we can customize uh the logic for tokens by uh updating uh uh pieces of of the account. And um as the model stands today, we want to um make sure that every um every uh account on nil is able to uh transfer whatever token it has within the shard and update its own state by doing that. And if a if a transaction is involved in another state, there is a separate uh uh token manager that updates the state for that account. So I think I can go now back to my first slide here. here. Yes. So, this is the meat of it. Um, we have for transactions that happen within a shard, I think it's very easy to imagine. This is particularly for the cross shard transaction. For transactions that happen within a shard, we just call the single token manager within that shard. But in a a cross shard transaction, uh the token manager is able to handle um uh token updates for uh cross shard transactions. So um it's a very very similar setup to uh what you would find in uh interop and ethereum. Difference being that uh uh the system handles uh uh uh token management across all shards. So uh the developer this is abstracted away from the developer uh particularly cross shard token communications. So uh let's continue here. Great. Okay. So how does that work with uh uh Dexus and DAP scaling? Uh we adapted uh unis swap v2 to uh make use of uh every shard. So instead like as I mentioned previously in my first example is that we had unis swap v2 with a sh a single shard in which one pool affects the gas prices for the whole network. Um which is not the best. So um with a multi-sharded design we're able to deploy a pool for every shard and then um yeah that way if there's one popular pool it will not affect the other pools uh in other shards. So uh every shard had had its own pool and uh whenever a user wants to perform uh say a multi-shard swap uh they will call multiple shards separately. So, it's one application of how to do a uh a DEX uh in multi-shart setups. Actually, that'll be it. So, thank you. [Applause] Thank you, Dennis. So, I think we've got time for a few questions. Um, so does anyone from the audience have a question? Okay, perfect. I'll hit you and then I'll head to you. Hey uh thanks for the talk. Uh could you please elaborate on eventual consistency for read operations? Let's say I have a smart contract that wants get get balance of specific account for your like pepe coin C20. How does it work? Thanks for read operations. It would be asking the token manager. Um that's how the design is will or is implemented is being implemented as we speak. Actually the token manager will handle read operations for uh your local shard for balances in some other shard. So balances for the token manager actually for any cross shard communication as it stands right now will be propagated among the other shards. Cool. I think we had another question over here. Perfect. Question time. Thanks for the presentation, Dennis. Um, my question I saw in the slides up to three shards at some point, but I'm I guess I'm wondering is there a mechanism to dynamically adjust the number of shards? Yeah, that's something we're working on right now. But uh for our mainet release, we will start with a fixed number of shards. Cool. Cool. Are there any more questions or Cool. I have a question. As someone who did not know what enshrined tokens are until 15 minutes ago, if there was sort of any key takeaway that you'd have for anyone who just learned about this concept today, what would you want them to walk away with? that on nil you don't need to uh worry of uh on uh there being uh a presence of your token in some other shard and you handling that yourself. Uh nil handles that for you. So your application is able if you deploy a token today on Ethereum you have to uh worry of on its presence on different shards on or different rollups actually uh on nil that's all handled for you. So you just have to deploy it on nil and then it's it's there for available in all shards. Amazing. Cool. Thanks, Dennis. So great.