Traditional DAO funding mechanisms rely on voting and committee mechanisms that are slow, gameable, and create deliberation bottlenecks. How can Allo create a self-sustaining system that incentivizes efficient allocation of capital while minimizing governance overhead?
Principles
To address this problem, this solution aims to be:
- Governance minimized: Reduce the need for human intervention, oversight, and deliberation in the decision-making processes.
- Expedient: Prioritize speed and responsiveness.
- Autopoietic: The system is self-sustaining and self-regulating.
- Single-threaded: Decisions and actions are executed in a linear, sequential manner to avoid diffusing attention.
- Incentive-compatible: Each participant’s best individual strategy aligns with the system’s goals, ensuring they act in the system’s best interest without needing external enforcement.
Solution Breakdown
The solution consists of four core mechanisms that work together:
(1) Registration: Selectooors & Vetted Builders
- Any verified human can register as a Selector without directly disclosing their identity.
- Why: Reduces the risk of undue influence or biases.
- Builders must apply through a form to be added to the builder pool. As part of their application they provide the minimum funding their project needs to launch.
- Why: Ensures only high-quality, mission-aligned candidates are eligible.
(2) Selection: Continuous Sortition & Delegated Domain Allocation
- Each
slot_duration(e.g. 4 hrs), a human is randomly chosen from the Selector pool to select one builder from the builder registry to fund.- Why: This perpetual rotation ensures fresh perspectives, distributes decision-making power, with a time-limited, low-friction process that maintains a continuous flow of funding allocations without deliberation bottlenecks.
(3) Distribution: Threshold-Based Dynamic Payouts
- Each
epoch_length(e.g. 25 slots), a percentage offunding_pool_rate(e.g., 1%) of the total funding pool is distributed to builders in proportion to the number of slots they were selected during the epoch, if the resulting amount is greater thandistribution_threshold(e.g. 10%) of their minimum funding level.- Why: This ensures builders receive meaningful funding amounts while maintaining continuous capital flow. The threshold requirement prevents fragmentation of resources across too many projects.
(4) Incentive Compatibility: Royalty Shares for Selectooooors
- Each epoch, Selectors receive royalty shares in the project that they selected, which grant them a proportional claim of the future fees generated by that project. Selectors can redeem their royalty shares against the project’s fee pool.
- Why: This ensures that Selectors’ rewards are directly tied to the long-term success of the projects they select, fostering a self-sustaining autopoietic system without requiring extensive oversight.
System Dynamics
The design creates an osmotic flow of funding where capital naturally moves toward value-creating projects through continuous, small decisions rather than large, discrete allocations.
The system creates two key feedback loops:
- Selector Alignment Loop: Royalty shares tie Selector rewards directly to project success, creating strong incentives for good selection and potential ongoing support/mentorship.
- Capital Efficiency Loop: Continuous allocation + threshold-based distribution ensures capital flows to projects that have demonstrated community support, while preventing over-fragmentation.
The system’s behavior can be tuned through four key parameters, each with their own tradeoffs:
slot_duration- Lower slot duration increases selection frequency, which gives more Selectors chances to participate, but may increase missed slots where selectors don’t react in time. Longer slot duration allows more consideration per decision but reduces system responsiveness.epoch_length- Longer epochs smooth out variance in allocation patterns, but delay builder payouts. Shorter epochs provide faster feedback but may lead to more erratic funding distribution.distribution_threshold- Higher thresholds ensure meaningful funding amounts but may concentrate capital in fewer projects. Lower thresholds enable more projects to receive funding but risk capital fragmentation.funding_pool_rate- Higher rates increase capital deployment speed but deplete treasury faster. Lower rates extend treasury longevity but may slow ecosystem growth.
Potential Modifications
Here are some ideas to enhance the core solution proposed:
- Stake-Weighted Selection - Each Selector can stake ALLO to increase their selection probability. This creates skin-in-the-game while maintaining permissionless participation, and helps prevent Sybil attacks on the selection process.
- Dynamic Builder Pools - Instead of choosing from all builders, Selectors choose from randomly generated subsets each round. Selection probability into these subsets is weighted by funding threshold - projects requesting more funding have higher chances of appearing. This balances the incentive to lowball minimum funding requirements.
- Reputation Scoring - Track Selector success rate based on royalties earned and use this reputation to influence future selection probability. Creates more intelligence over time in the system’s allocation decisions.
- Dynamic Funding Pool Rate - Rather than fixed parameters, the system could self-adjust based on real-time metrics. For example: funding pool rate could increase when treasury utilization is high and project returns are strong; selection slot duration could lengthen when Selector vacancy is high; distribution thresholds could lower when too few projects are reaching funding goals. This creates a more responsive system that optimizes itself based on actual usage patterns.
Resources
- Identity verification: Gitcoin Passport
- Sortition mechanisms: Kleros court
- Royalty splits: Drips, Splits, Revnet