Octant is best classified as a staking-yield-funded public-goods allocation system, not merely as a grants marketplace. Users lock GLM, accrue epoch-based budget, and then steer that budget in allocation windows.
The mechanism is explicitly time-weighted. Both user-facing copy and the Deposits.sol comments emphasize that when you lock and unlock matters for reward eligibility, because effective deposit is computed across the epoch rather than by static snapshotting of balances alone.
Octant’s most reusable design choice is the split between user budget formation and project matching. User rewards come from one part of the epoch economics, while project matched funding is calculated separately from staking proceeds, patron rewards, and locked-ratio policy.
The matched-funding engine is not fixed. The repo exposes threshold-controlled behavior based on the total locked ratio (IRE and TR), meaning the system changes how much staking-derived matched funding it contributes depending on how much GLM is effectively locked overall.
The quadratic-funding layer is also modified in two important ways: it multiplies user allocations by anti-sybil uniqueness scores before taking square roots, and it caps any single project’s matched rewards at 20% of the total matched pool.
Octant therefore belongs in the corpus as a hybrid mechanism: part staking-yield router, part allocation game, part anti-sybil-weighted CQF system.
The user docs and router docs show another important control plane: anti-sybil policy. Gitcoin Passport-based scores are converted into coarse UQ buckets that directly affect matched-funding weight.
Patron mode is a separate mechanism worth retaining. It is not just a UI convenience; it is an alternative path for routing a user’s budget into shared project support instead of individualized project-by-project steering.
Current product strings show the protocol is mid-evolution. Octant v2 migration is built into the live app flow, so the project should be treated as an actively changing governance and funding system rather than a settled one.
Specific source signals worth retaining
Repo README: frames Octant as a Golem Foundation experiment in decentralized governance, user control, voter engagement, and community funding.
Deposits.sol: shows lock timing is integral to the economics and warns that deposit-contract complexity should stay low even if it pushes complexity elsewhere.
backend/v2/matched_rewards/services.py: spells out the locked-ratio-dependent matching formula and shows patron rewards are always included.
backend/v2/project_rewards/capped_quadratic.py: documents the uniqueness-weighted CQF formula and the 20% matched-funding cap.
backend/v2/users/router.py: documents Gitcoin Passport-derived UQ scores and their use in anti-sybil handling.
client/src/locales/en/translation.json: provides unusually direct product-language explanations of weighted-average rewards, unlock penalties, patron mode, and the v2 migration flow.
Why this entry belongs in the corpus
Octant is valuable because it combines several mechanisms that often appear separately elsewhere: token locking, yield routing, anti-sybil scoring, quadratic matching, allocation windows, and a patron/pool path.
It is especially useful for comparisons with clr.fund and Gitcoin-style quadratic funding because it shows a different answer to the same question: how do you turn community preference into public-goods allocation without letting one layer completely dominate the rest?
The reusable insight is that yield-source design and participation-budget design can matter as much as the matching formula itself. Octant’s power is in how it composes these layers, not just in the QF math at the end.