Madhavan MalolanPermissionless Hierarchy : A new way to look at DAOs.
DAOs are the biggest misnomer of web3. They don’t work, and no one seems to know how to make it work. Here, I present a view to challenge the way we look at DAOs to begin with. The take-away for me from 2 days of DAO discussions in Amsterdam is nobody has figured out how to manage the chaos to get anything useful done in a DAO. DAOs are today just a glorified Discord channel with no clear route to be either Decentralized (what does that even mean?) or Autonomous. “DAO” is a marketing gimmick....
Madhavan MalolanRequest to build - Decentralized NFT based lending protocol
A completely decentralized protocol that lets people borrow money from the treasury by producing an NFT. This is to be built on top of LooksRare, because LooksRare is decentralized and hence infinitely composable.Borrow at floor priceProduce an NFT from an NFT collection on LooksRare. The maximum amount you can borrow against the NFT is the minimum floor price of that collection over the last 30 days. You can only deposit verified collections’ NFTs - for securing the protocol. Open to any oth...
Madhavan MalolanRequest to build - A decentralized Audit Marketplace mechanism design
Auditing wait times on top audit firms are 9-12 months and expensive. We need something that is more participative and allows for new and yet-unproven security auditors. Here I propose a decentralized audit marketplace that turns the auditing process into a prediction marketplace.1. Select a juryA jury is usually reputed security engineers. This jury doesn’t do the audit itself, but only signs off a reported vulnerability as a real bug. There are 5 jury members selected for every audit. They ...
Founder [Questbook (YCw21)](https://questbook.xyz) Writing about things that need to be built in web3
Madhavan MalolanPermissionless Hierarchy : A new way to look at DAOs.
DAOs are the biggest misnomer of web3. They don’t work, and no one seems to know how to make it work. Here, I present a view to challenge the way we look at DAOs to begin with. The take-away for me from 2 days of DAO discussions in Amsterdam is nobody has figured out how to manage the chaos to get anything useful done in a DAO. DAOs are today just a glorified Discord channel with no clear route to be either Decentralized (what does that even mean?) or Autonomous. “DAO” is a marketing gimmick....
Madhavan MalolanRequest to build - Decentralized NFT based lending protocol
A completely decentralized protocol that lets people borrow money from the treasury by producing an NFT. This is to be built on top of LooksRare, because LooksRare is decentralized and hence infinitely composable.Borrow at floor priceProduce an NFT from an NFT collection on LooksRare. The maximum amount you can borrow against the NFT is the minimum floor price of that collection over the last 30 days. You can only deposit verified collections’ NFTs - for securing the protocol. Open to any oth...
Madhavan MalolanRequest to build - A decentralized Audit Marketplace mechanism design
Auditing wait times on top audit firms are 9-12 months and expensive. We need something that is more participative and allows for new and yet-unproven security auditors. Here I propose a decentralized audit marketplace that turns the auditing process into a prediction marketplace.1. Select a juryA jury is usually reputed security engineers. This jury doesn’t do the audit itself, but only signs off a reported vulnerability as a real bug. There are 5 jury members selected for every audit. They ...
Founder [Questbook (YCw21)](https://questbook.xyz) Writing about things that need to be built in web3
Share Dialog
Share Dialog
Subscribe to Madhavan Malolan
Subscribe to Madhavan Malolan
<100 subscribers
<100 subscribers
The traditional models of software architectures don’t apply to decentralized dapps. We need a new paradigm. Here, I outline a new architecture for DApps that are completely decentralized. It’s called SACI, pronounced Sassy (because it is).
The 4 components in this architecture are
Decentralized Storage
Decentralized App
Smart Contract
Decentralized Indexer
So - Storage, App, Contract, Indexer = SACI
In the architecture, the data is not stored on a centralized database. The data is stored as Blobs on a decentralized storage service. These blobs are then referenced by their unique identifier (e.g. MD5Sum, IPFS Hash)
This storage stores
The App itself, which is served for execution on the client side (more on this in the next section)
User generated data - both encrypted and un-encrypted depending on the data type
The data is stored by encrypting it with the public keys of the users who are allowed to decrypt the data. This data can be retrieved by an application by the reference identifier and then decrypted on the client side using the private keys.
IPFS, FileCoin, Arweave
The app is one that runs completely on client side. E.g. React apps without SSR, mobile applications (APK/IPA), single page websites.
What is not an application is one that is served by a server where there is some computation and authentication that happens on the backend. For example, in the MVC model, the controller has access to modifying the views on the backend. In SACI all the business logic is executed strictly on the client side / frontend.
The app is usually responsible for
All the business logic and user interfaces are displayed by the application. If this is a web application, it should be noted that this comes with its own security constraints. Code that executes on a browser is insecure. That brings us to the next responsibility of the App.
All the user interactions necessarily happens on chain (ideally). So it requires the user to sign every transaction that happens. Even for transactions that aren’t necessarily posted on to the main chain to save gas, they must be signed and stored on an L2 or rollup.
Every user interaction is valid only if it has a signature to it.
The business logic requires data. This data can be fetched via RPCs for on chain data or APIs exposed by the indexer.
React, Flutter (without SSR)
As discussed in the section above, all the user interactions ideally are recorded on-chain. If the user is creating a post, it’s on chain. If the user is creating a profile, it’s on chain …
The way to save data is to create a transaction on the chain. This contract should emit an event when the transaction is completed.
The best way to save the data is to create a blob of data, put it on a decentralized storage service and save the reference to that blob. When the contract emits the reference to the blob, the event is listened to by the indexer.
The data can be retrieved by a combination of querying the contract/indexer and the decentralized storage service.
The best way to store data is to emit events. This event can then be indexed by the indexer and made available for later use. This is better than saving the data completely on chain, to save gas fees.
Ethereum, Optimism, Polygon, StarkNet and all other programmable L1/L2/Rollups
The indexer is responsible for capturing all the data that is emitted by the contract. The indexer is the closest to a controller on the MVC model. The indexer is responsible for capturing the data from the contract, processing it and saving it in a way that can be queried later. Ideally the indexer is also a decentralized system that allows for the system to not have a single point of failure.
This is an optional step to optimize resource consumption.
The indexer will store information only when the data emitted by the contract is in the correct schema. The indexer will query the verification service to check the sanctity of the data before storing it.
The verification service allows the data to be consistent and clean.
Graph, Covalent
This architecture is optimized for complete decentralization. The point here being that the service provided by your dapp has the following properties.
It requires all the data to be available for any service to consume. It is not required that the product used only via the application. The product can be used by other services via a different UI, or other contracts that bypass the app completely.
All the components are open sourced. The contract, indexer logic & the app (if it is a web app) are by definition open sourced. No one needs to trust this dapp - they can see all the code and be sure about the business logic.
All the data that is generated by the user requires a wallet signature and/or encryption. Meaning that the data is always in the control of the end user and cannot be censored, manipulated or used without consent.
The traditional models of software architectures don’t apply to decentralized dapps. We need a new paradigm. Here, I outline a new architecture for DApps that are completely decentralized. It’s called SACI, pronounced Sassy (because it is).
The 4 components in this architecture are
Decentralized Storage
Decentralized App
Smart Contract
Decentralized Indexer
So - Storage, App, Contract, Indexer = SACI
In the architecture, the data is not stored on a centralized database. The data is stored as Blobs on a decentralized storage service. These blobs are then referenced by their unique identifier (e.g. MD5Sum, IPFS Hash)
This storage stores
The App itself, which is served for execution on the client side (more on this in the next section)
User generated data - both encrypted and un-encrypted depending on the data type
The data is stored by encrypting it with the public keys of the users who are allowed to decrypt the data. This data can be retrieved by an application by the reference identifier and then decrypted on the client side using the private keys.
IPFS, FileCoin, Arweave
The app is one that runs completely on client side. E.g. React apps without SSR, mobile applications (APK/IPA), single page websites.
What is not an application is one that is served by a server where there is some computation and authentication that happens on the backend. For example, in the MVC model, the controller has access to modifying the views on the backend. In SACI all the business logic is executed strictly on the client side / frontend.
The app is usually responsible for
All the business logic and user interfaces are displayed by the application. If this is a web application, it should be noted that this comes with its own security constraints. Code that executes on a browser is insecure. That brings us to the next responsibility of the App.
All the user interactions necessarily happens on chain (ideally). So it requires the user to sign every transaction that happens. Even for transactions that aren’t necessarily posted on to the main chain to save gas, they must be signed and stored on an L2 or rollup.
Every user interaction is valid only if it has a signature to it.
The business logic requires data. This data can be fetched via RPCs for on chain data or APIs exposed by the indexer.
React, Flutter (without SSR)
As discussed in the section above, all the user interactions ideally are recorded on-chain. If the user is creating a post, it’s on chain. If the user is creating a profile, it’s on chain …
The way to save data is to create a transaction on the chain. This contract should emit an event when the transaction is completed.
The best way to save the data is to create a blob of data, put it on a decentralized storage service and save the reference to that blob. When the contract emits the reference to the blob, the event is listened to by the indexer.
The data can be retrieved by a combination of querying the contract/indexer and the decentralized storage service.
The best way to store data is to emit events. This event can then be indexed by the indexer and made available for later use. This is better than saving the data completely on chain, to save gas fees.
Ethereum, Optimism, Polygon, StarkNet and all other programmable L1/L2/Rollups
The indexer is responsible for capturing all the data that is emitted by the contract. The indexer is the closest to a controller on the MVC model. The indexer is responsible for capturing the data from the contract, processing it and saving it in a way that can be queried later. Ideally the indexer is also a decentralized system that allows for the system to not have a single point of failure.
This is an optional step to optimize resource consumption.
The indexer will store information only when the data emitted by the contract is in the correct schema. The indexer will query the verification service to check the sanctity of the data before storing it.
The verification service allows the data to be consistent and clean.
Graph, Covalent
This architecture is optimized for complete decentralization. The point here being that the service provided by your dapp has the following properties.
It requires all the data to be available for any service to consume. It is not required that the product used only via the application. The product can be used by other services via a different UI, or other contracts that bypass the app completely.
All the components are open sourced. The contract, indexer logic & the app (if it is a web app) are by definition open sourced. No one needs to trust this dapp - they can see all the code and be sure about the business logic.
All the data that is generated by the user requires a wallet signature and/or encryption. Meaning that the data is always in the control of the end user and cannot be censored, manipulated or used without consent.
No activity yet