This article explains what the Extendable DAO is and how it works. We also provide an example repository where you can clone and run it yourself. This example requires prior knowledge of how smart contracts work on Algorand, and the extendable functionality requires experience of smart contract development. This work has not been audited and there are a few deliberate choices in the example which make it unfit for production without alteration. Please see the concerns section for more information.

A Decentralised Autonomous Organisation or better known as a DAO can come in many different forms depending on who it’s aimed at, the purpose of it, as well as where in the world it’s being used. It’s an increasingly large topic of its own, and you can learn more about them using the DAO Entity Matrix from Paradigm.

Extendable DAO

So what does the Extendable DAO do? On its own it doesn’t do much, but as its name suggests it has the capability to be extended to do whatever you want it to do. This allows developers to implement new functionality which is unique and suitable specifically for their DAOs requirements.

For example, do you need treasury management? Then deploy/propose the functionality and have the DAO members vote on its adoption. Or maybe you have an investment DAO which needs to be able to interact directly with an AMM DEX for converting the assets it holds to/from stable assets? Again you can propose a solution for this and have the members vote on introducing these functionalities.

Extended Functionality

When creating functionality for the DAO it must conform to a standard design, this is so that the DAO knows how to interact with it. For PyTeal this means placing the code at the start of the program, with the functions at the end, as once it’s compiled to bytecode the ABI methods will then be located at the start of the approval program, with the implementation of these methods located at the end of the approval program. Allowing for custom functionality to fill the middle of the contract. This way the DAO verifies during the proposal stage that the functionality includes predefined features that are necessary, such as the ‘activate’, ‘deactivate’, and ‘invoke’ methods.

Beyond the standard functionality, a developer may choose to do whatever they wish once the invoke method has been called. This will primarily include inner transactions with the Sender set to the DAO’s own application address. The reason this is possible is because every invocation of extended functionality includes a rekey of the DAOs account to the application being called. However the invoke will only succeed if the functionality also removes the rekey once it’s completed its own processes, making sure that future invokes of other functionality will be possible. This does mean though that the extended functionality really must be audited before members cast their vote to implement it. See the concerns section to find out more information.

Demo

Using the repository ExtendableDAO , we’ll now step through the entire process of how the Extendable DAO works. Please note that this demo won’t show off anything overly complicated, and will simply demonstrate the functionality of being able to opt the DAO into additional ASAs. The repository also contains functionality for making a trade on the PactFi AMM , but that’s left up to the reader to implement.

The following steps should get you up and running with an instance of the ExtendableDAO.

# Navigate to your Sandbox folder
./sandbox up dev -v

# Clone the repostiroy
git clone [email protected]:algorand-devrel/ExtendableDAO.git
cd ExtendableDAO

# Launch the reactjs UI from within the ExtendableDAO directory.
npm install
npm run start

Stage 0 - Deploy DAO

This simply deploys a new DAO smart contract to your sandbox. By default it will be uninitialised and will require a second step to complete the deployment. The deployment is a single application transaction (appl) and uses the ARC4 ABI compliant method call deploy(string)void. We specify 64 global ints and 16 local ints for the state schema, this is to maximise the amount of votes that can take place at any one time, however you may wish to reduce these.

Stage 1 - Create DAO Token

The DAO allows for any existing ASA to be used as the native token, but in this example we will create a new ASA called “DAO Token”. We also OptIn a new account (the voter in our case) into the new ASA and send them 20 DAO Token.

Stage 2 - Initialise DAO

This is the second step required to complete the deployment of the DAO. This allows the DAO to opt in to the DAO Token and enables the ability to start proposing new functionality. The initialisation call is a single appl transaction and uses the ABI method initialise(asset)bool. The asset opt-in is done by the smart contract making an asset transfer inner transaction, with the fee being paid by the sender, so the transaction cost is 2000 microAlgos.

Stage 3 - Create Fake ASAs

For this demo we will be demonstrating how to extend the DAO with the functionality of opting into additional ASAs, so first we’re going to create two fake ASAs, fake USDC and fake USDT. Nothing fancy is going on here, we’re just creating two new assets to demonstrate the functionality we will add next.

Stage 4 - Propose Functionality

Now we can deploy our new functionality to the network and in the same group call the DAOs proposal method, instigating a new vote for the implementation of this functionality. This step requires a group of two transactions. First is the deployment of the functionality by the proposer, which is an ABI method deploy()void. The second transaction is an application call to the DAO with the ABI method propose(appl)uint64. The deployment of the functionality has to be done at the same time as the propose, this allows the DAO to perform some checks on the approval program to verify it has the appropriate method calls, and wouldn’t be rejected upon activation.

Stage 5 - Voting

Now all users of the DAO can vote for or against the implementation of the new extended functionality. This is done by calling the ABI vote(application,axfer,bool)bool method. This allows the DAO to identify which proposal you’re voting for, the amount you wish to vote with, and a boolean indicating for (true) or against (false). Sending the DAO Tokens into the DAO must be within the same group transaction so the value can be stored against their local state. Sending the assets on their own would result in losing their assets. Unfortunately this process has limitations on how many simultaneous votes can occur, see the concerns section for more details.

In a real-world scenario you would likely place a fixed duration on the voting process, however this demo has included the ability to end the voting once you’ve voted for/against. (Note that you need to have voted in favour of the functionality to proceed with the demo).

Stage 6 - Activate

To implement the functionality natively for the DAO it must now be activated. This will only work if the votes are in favour of it. Once it’s activated the original proposer may deactivate (delete) their proposed smart contract, letting them free up their minimum balance requirement.

The activation call is a single application call to the ABI method activate(application)uint64. This will cause the DAO to perform an inner transaction and deploy the new functionality as a smart contract under its own application account. It would be a good idea to check the account had been funded enough to maintain the higher minimum balance requirement after activation.

Since the voting process has ended all users may now reclaim their DAO Tokens.

Stage 7 - Invoke

Now you can invoke the DAO, calling the new functionality. This demo allows us to OptIn to both the fake USDC and fake USDT. After which we can then send 10 UDSC or USDT to the DAO as proof that it is opted in!

Conclusion

An underutilised area of Algorand Smart Contracts is the contract-to-contract calling and also the rekeying features. This demonstration should have given you an understanding of new ways it can be used. The concept of an initial application which can continue to be “upgraded” with new functionality is certainly interesting. One alternative option would be to allow the DAO smart contract itself to have an UpdateApplication call issued to it which contained new approval/clearstate TEAL, however this feels more risky and also introduces a size limitation on how many features it can have.

Hopefully this article and the demonstration of what the Extendable DAO is capable of has inspired you to take advantage of it, or build your own version. All the code is available for you to download, use, and modify. If you have any improvements please feel free to submit a PR, or if you have any questions or just want to discuss other Algorand related subjects join the Algorand Discord .

Concerns

Below are various concerns as I’ve pointed out throughout the article. They’re not impossible to resolve, but for the simplicity of this demonstration they have been left to the reader to implement.

Whilst the current checks to the functionality during deployment/proposing are minimal, it’s possible to enhance the checks against the proposed approval program before the proposal can be made. Right now a small number of bytes are actually checked, so could be bypassed by clever developers.

Extended functionality has no real limits, so it’s entirely possible that a malicious developer implements something that looks right, but may have a malicious “backdoor”. A typical DAO user is probably not capable of auditing a smart to find such problems, so having a reputable auditor review the contract is still important.

Users can only vote on one proposal at a time given that their DAO Tokens must be held by the DAO until after the vote has taken place. This isn’t great, but without holding the ASAs you cannot be sure that the user hasn’t moved their assets to another account and voted with the same assets twice.