The Lid Leaks: What Mumbai Dabbawalas Teach Private Finance

Transcript

[music] [music] Yes, welcome to the most cliche talk of Devcon. Guys, I really want to explain to you that every conference I've been to in Mumbai has at least touched upon the Mumbai's daalas at least once, right? And this is I guess my opportunity or my obligation to do it for you as well. And let's see what we can learn from them to actually understand how private finance works.

That's something called a daba roughly translated a daala is a box person in Hindi. And essentially at their peak Mumbai's dabalas delivered about 200,000 lunch boxes a day. They have been organized since 1890. And even up until today, there's are about 3,000 dabalas consistently delivering lunch boxes to office workers every day.

How does the system work? Well, there are several steps involved, but essentially someone comes to your home, they pick up the lunchbox and then it goes to a collection station. After that, it transfers hands to the local station and then they take the train. It reaches the destination station and then is finally distributed to your office. Now, once you're done with lunch, it follows the same way back. And I guess in looking at this sort of pathway we can understand some of the properties that this system has.

The first property is that there are many intermediaries involved. The second is that there is one shared standard. All the boxes look the same more or less and your daala does not actually look into the contents of the box and does not eat the food that was meant for you. Coincidentally, these are the same properties that financial institutions want when they try to look at onchain finance. So the many intermediaries here are banks, custodians, and brokers. The one shared standard essentially could be interpreted in a couple of different ways. either you have a shared ledger or you have a shared token standard. And finally, they don't want their

intermediaries to see more than what is required for their transactions. In a similar manner as to how you can carry different kinds of food in your boxes, many financial instruments can also be packaged into boxes on chain uh ranging from bonds, stocks, money market funds, stable coins, etc. Given that India's particular interest into onchain finance is more recently related to bonds, uh let's look at some of the problems with bonds on chain.

If we were to largely group the life cycle of a bond, it would be issuance, eligibility, transfer and resale and finally audits. Now in the traditional system, it works really well. However, there are certain capital inefficiencies that arise and that is the main reason why uh tokenized bonds are becoming uh such an important factor for financial institutions to consider in their operating road map.

As you can see there the problems that I've mentioned. So at issuance you have every holding being public eligibility. How do you bridge offchain data that is your KYC to onchain uh cryptographic primitives? You have transfer and resale. You might want to keep the bonds uh sale price private. And there is no scoped way for an auditor to look at anything because everything might be public as well. Let's look at how putting bonds on different kinds of ledgers, how it addresses some of the requirements that they might want. So on a public chain, you can have multiple intermediaries, you can have a shared

standard and nobody reads the contents that is not really addressed because everyone can see your transactions in the clear. If we look at permission chains, you sort of lose the multiple intermediaries because you either have to go through the consortium networks uh super node or you would have to essentially participate with a bridge. So you lose the opportunity on having multiple intermediaries. The shared standards is a little problematic because while one consortium might use one token standard, another could use a different one. And finally, when it comes to nobody reads the contents,

ultimately the operator of such a consortium network could see the contents and uh in future designs, we can see that that's sort of being mitigated. Finally, we have Ethereum with cryptography. Now I don't want to shill it but essentially we tick all of these boxes except for a few nuanced observations. If we zoom into the black box itself when I mentioned Ethereum with cryptography what kind of cryptography right so let's walk through the life cycle of a bond while keeping the cryptography in mind you can see that there are multiple parties on the screen

the issuer two investors and the regulator issuer essentially uh issues the bond on chain and makes certain pieces of data public like the bond ID supply and maturity they can choose choose whether to disclose this or not if they would like and then you have an investor A. Investor A would want to prove that they are eligible to purchase this specific bond. So they can use a sort of membership proof or a cryptographic proof that they are eligible to do so.

Finally, you have investor B who wants to participate in the sale of such a bond and wants to ensure that it changes hands from investor A to themselves in a private manner. And then we have the regulator who wants to be able to see what actually happened to the bond throughout its entire life cycle. And it gets a scoped view of what it should see. There are several solution families that can be used to implement this cryptographic blackbox. You have shielded nodes uh which is your privacy pools. You have privacy L2s, FHE as well

as MPC. All of these solution families have multiple trade-offs. And it ultimately privacy is not a silver bullet, right? You have to understand the use case very deeply to be able to understand which specific family of solution you can use and at each systems we help institutions do that through the use of several starter kits. So let's look at the trade-offs in a little more detail. Right? broadly bucketed you have metadata anonymity set and data residency as some of the problems when it comes to confidentiality on chain and for metadata I'm going to go back to

the analogy of the Mumbai daalas here on the screen you can see that there is a uh a bag which has certain routing information written on it in a similar manner depending on the solution family that you use you could have several pieces of metadata data that are exposed to the public. So for shielded pools in specific, you have the origin and destination of a particular uh life cycle which are exposed as in the entry to the blackbox and the exit from the blackbox ends up being public timing across multiple different um effects that you have. and finally

counterparties in specific solutions which don't hide addresses. When it comes to the anonymity set, uh this is something that institutions should really care about because if they try to KYC and only ensure that for example five institutions can participate in uh the sale of bonds then every transaction that is visible will be from one of those five institutions. So it is imperative that the anonymity model or the privacy model here is uh strict enough to ensure that everyone maintains a certain level of privacy.

And finally we come to data residency. Whenever you have a private solution that depends on Ethereum in any way there is some form of state that is stored onchain. Now to receive that state to be able to perform any computation on it or to actually execute private transactions you need to fetch the data from the L1 and in doing so you might actually leak some metadata about who you are based on the specific data that you're requesting. So at Eat Systems we've sort of developed a solution. This is called PI. It's been around for a long time but we've used it in several of our starter kits. It's

called private information retrieval. It essentially hides what data is being read but uh sort of reveals how old the data is. So that's something to take into consideration as well. In each systems lunchbox we have uh ZK eligibility entry uh hidden transfers. We have atomic bond for stable coin swaps, viewing viewing key audits and P wallet reads. However, we've specified a lot more designs and essentially you would want to compose your lunchbox with all of these different pieces.

Finally, if we try to understand uh how all of these ledgers stack up when it comes to the main title of the talk, does the lid leak? Uh the public chain does. Yes. The permission chain does. Yes. And with Ethereum with cryptography, you can choose what you want to leak. This is what we've done so far and what we have designs for right now. And this is the question that you should ask yourself if you are a financial institution. Uh is what fits your trust model. That's it. Thank you.

I think we have a couple of minutes for questions. >> Are there any questions? >> That is a great question. Uh happy to discuss offstage and I can walk you through everything from scratch. Uh someone said, "Hi, I couldn't understand. And can I get a TLDDR? >> [music]