Understanding the StackerDAO Architecture: A Deep Dive into DAO Design Philosophy

DAOs—Decentralized Autonomous Organizations—are incredibly powerful. They are designed to elegantly manage complex systems involving multiple components in a simple, modular way. With DAOs, you can manage members, decision-making processes, asset creation and distribution, and you can do all of this with transparency, security, and autonomy.

In this post, we’ll dive deep into the structure and functionality of the StackerDAO project. Along the way, we’ll explore its key features, unique elements, and how its architecture embodies DAO design principles in a practical, modular, and scalable manner.

I have included the Github repository so you can follow along: https://github.com/StackerDAOs/backend

Now the design philosophy itself is so simple that it is profound. And it goes like this:

---

"The Core executes, while the extensions give form."

This principle means that a DAO can be split into a central contract—the Core—and multiple separate Extension contracts. The Core handles only essential execution logic, while Extensions handle specific functionalities and processes.

---

Structural Overview

The Core contract includes only a small set of essential functions. Meanwhile, Extension contracts contain logic tailored to your organization’s needs.

This modularized structure allows you to:

• Compartmentalize business logic

• Govern team structure, treasury, and policy management

• Achieve autonomy and transparency

• Maintain flexibility as your organization grows

You can add or activate new extensions as needed, without breaking existing dependencies or wasting development time in the future.

---

Functional Flow of a DAO Process

Here’s how the typical DAO process works in a DAO system:

1. A governance token holder submits a proposal (which is itself a smart contract) to the proposal submission contract.

2. If conditions are met, the proposal is forwarded to the proposal voting extension contract, where members can vote.

3. After the defined voting period ends, the voting extension invokes the Core's execute function.

4. The Core contract checks that the call is authorized and then executes the original proposal. The proposal’s own execute function performs the logic approved by the DAO members.

This process isn’t just for executing decisions; it can:

• Enable/disable extensions

• Modify the core

• Govern the DAO’s entire operational lifecycle

---

Core Contract Overview

The Core (executor-dao) contract contains several important public functions:

• execute: Executes the logic contained in the proposal using the DAO's authority.

• init: Initializes the DAO by activating extensions.

• set-extension: Enables or disables extensions within the DAO.

And, in line with best practice, the Core contract also contains a private function called:

• is-self-or-extension: This authorizes only the DAO itself or an enabled extension to call core functions, ensuring tight security controls.

So far, we’ve only explored the logic embodied by these three public functions and one private security function in the Core contract. These enable and execute proposals. All other responsibilities—rules, logic, policies, token vaulting, etc.—are delegated to extensions and proposal contracts.

The StackerDAO also defines a collection of tokens for different projects like CityCoins, MiamiCoin, and NewYorkCoin. They are all SIP-010 compliant, with some acting as governance tokens and some possessing delegation functionality.

---

Extensions Overview

Now let’s examine some important extensions used in StackerDAO and their purposes:

Extension 1: sde-emergency-execute.clar

• Defines an emergency executive team with special privileges.

• Allows emergency proposals with time-sensitive execution.

• Features:

  • Set emergency proposal duration

  • Set a sunset period (disabling after a certain timeframe)

  • Add/remove emergency team members

Only emergency members can submit proposals before the sunset period ends.

---

Extension 2: sde-token-lockup.clar

• Implements a lock/unlock token mechanism by minting a proportional amount of a wrapped fungible token (Locked-Mega) to represent voting power.

• Key Features:

  • • Locks tokens from a user and transfers them to the contract.

      • Mints equivalent Locked-Mega tokens to represent the stake.

      • Allows unlocking by returning the exact locked amount and burns Locked-Mega.

---

Extension 3: sde-membership.clar

• Manages authorized members and a blacklist system.

• Functions:

  • set-member: Add/remove members (not blacklisted)

  • is-member: Check membership status

  • set-blacklist: Add/remove users from blacklist

  • is-blacklisted: Check if user is blacklisted

---

Extension 4: sde-dev-fund.clar

• Defines a fund with a monthly token allowance for developers.

• Developers can claim their allowances via the claim public function.

---

Extension 5: sde-token-vesting.clar

• Implements a vesting mechanism for developers to claim governance-token-with-lockup tokens.

---

Extension 6: sde-multisig.clar

• Defines a multi-signature system that can add or remove signers, and manages signals required to add and sign proposals.

• Key Features

  • Adds/removes signers

  • Manages signal thresholds for executing proposals

---

Proposals Overview

Now let’s look at a few proposals in StackerDAO. Remember, proposals are also smart contracts. This makes them precise and programmable representations of DAO operations.

Proposal 1: sde-proposal-submission-with-delegation.clar

• This uses the governance token to ensure the caller is authorized, makes sure the required parameters are valid, then, executes the passed proposal by calling .sde-proposal-voting-with-delegation

Proposal 2: sde-proposal-submission-with-lockup.clar

• Similarly to Proposal 1, this uses the governance token to ensure the caller is authorized, makes sure the required parameters are valid, then executes the passed proposal by calling .sde-proposal-voting-with-lockup

Proposal 3: sde-proposal-submission-members.clar

• Stores the contract that manages DAO membership, manages the timing of the proposal execution process; ensures only authorised members can call the propose funtion; then executes the proposal by calling .sde-proposal-voting-with-members

Proposal 4: sde-proposal-submission-with-nft.clar

• Creates and manages the execution of a passed proposal based on the authorized caller owning the specified NFTs and calls .sde-proposal-voting-with-nft

Proposal 5: sde-proposal-submission.clar

• Manages proposal submission using a governance token to ensure authorized callers with a threshold amount can call the propose function, which in turn, executes the passed-in proposal by calling .sde-proposal-voting-with-external-lockup

Proposal 6: sde-vault.clar

• This is a vault that allows the DAO to whitelist assets, manage deposits and transfers, and enforce access control through DAO governance.

---

Conclusion

To summarize what we have learned in this tutorial.

The Core executes, while the extensions give form. This means that you have one smart contract that acts as a core and then you can have one or more separate contracts that act as extensions.

This is a single-address ownership model and the core contract is the de facto owner of the external ownable contracts.

Extensions are contracts that can be enabled or disabled by proposals and add specific features to the DAO.

The core contract, the extensions, and the proposals are all smart contracts.

This gives us the three core tenets of DAO design:

1. Proposals are smart contracts

2. The Core executes, Extensions give form

3. Ownership is controlled via sending context

   Thanks for reading!