3f9abb5a3a
- Source: inbox/archive/2025-02-06-futardio-proposal-should-sanctum-implement-cloud-staking-and-active-staking-re.md - Domain: internet-finance - Extracted by: headless extraction cron (worker 3) Pentagon-Agent: Rio <HEADLESS>
61 lines
3.6 KiB
Markdown
61 lines
3.6 KiB
Markdown
---
|
||
type: entity
|
||
entity_type: decision_market
|
||
name: "Sanctum: Should Sanctum implement CLOUD staking and active staking rewards?"
|
||
domain: internet-finance
|
||
status: passed
|
||
parent_entity: "[[sanctum]]"
|
||
platform: "futardio"
|
||
proposer: "proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2"
|
||
proposal_url: "https://www.futard.io/proposal/4BTTxsV98Rhm1qjDe2yPdXtj7j7KBSuGtVQ6rUNWjjXf"
|
||
proposal_date: 2025-02-06
|
||
resolution_date: 2025-02-09
|
||
autocrat_version: "0.3"
|
||
category: "mechanism"
|
||
summary: "Implement CLOUD staking with 30-day vesting lockup and allocate 30M CLOUD (3% supply) to active staking rewards over 6 months"
|
||
tracked_by: rio
|
||
created: 2026-03-11
|
||
---
|
||
|
||
# Sanctum: Should Sanctum implement CLOUD staking and active staking rewards?
|
||
|
||
## Summary
|
||
|
||
Sanctum's CLOUD-1 proposal (passed 2025-02-09) implements two governance mechanisms: (1) staked CLOUD (sCLOUD) with 30-day linearly vesting lockup as the base asset for futarchy participation, designed to mitigate Keynesian beauty contest dynamics by filtering for long-term holders, and (2) active staking rewards distributing 30M CLOUD (3% of total supply) over six months to participants based on (stake × time) × vote count with 10 USDC minimum trading volume per proposal.
|
||
|
||
The proposal represents Sanctum's adoption of MetaDAO's Autocrat v0.3 futarchy infrastructure with custom extensions for staking and participation incentives. It plans biweekly governance cadence (1 week deliberation + 3 day voting) and explicitly delays transitioning to sCLOUD/USDC markets until users are comfortable with the mechanics.
|
||
|
||
## Market Data
|
||
|
||
- **Outcome:** Passed
|
||
- **Proposer:** proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2
|
||
- **Proposal Account:** 4BTTxsV98Rhm1qjDe2yPdXtj7j7KBSuGtVQ6rUNWjjXf
|
||
- **DAO Account:** 5n61x4BeVvvRMcYBMaorhu1MaZDViYw6HghE8gwLCvPR
|
||
- **Autocrat Version:** 0.3
|
||
- **Completed:** 2025-02-09
|
||
|
||
## Key Mechanisms
|
||
|
||
**Staking Lockup:**
|
||
- 30-day linearly vesting lockup (~3.3 CLOUD/day per 100 sCLOUD unstaked)
|
||
- Designed to filter for long-term holders and reduce short-term speculation
|
||
- Framed as solution to "primary potential failure mode of futarchy" (beauty contest)
|
||
|
||
**Active Staking Rewards:**
|
||
- 30M CLOUD (3% of total supply) allocated over 6 months
|
||
- Distribution formula: (staked CLOUD × time) × vote count
|
||
- Minimum 10 USDC trading volume per proposal to qualify
|
||
- Two 15M tranches, quarterly distribution, first ~3 months after passage
|
||
- Voting tracked starting from CLOUD-2
|
||
|
||
## Significance
|
||
|
||
This proposal is significant for futarchy mechanism design because it introduces two novel extensions to the base Autocrat architecture: staking lockups as a beauty contest mitigation strategy and active rewards as a participation incentive. Both are theoretical mechanisms without empirical validation—the proposal represents a live experiment in whether these additions improve governance quality versus introducing new attack vectors (e.g., mercenary capital farming minimum rewards).
|
||
|
||
The staged rollout approach (delaying sCLOUD/USDC transition until users are comfortable) also reveals adoption friction in futarchy implementations, suggesting mechanism complexity requires gradual onboarding rather than immediate full deployment.
|
||
|
||
## Relationship to KB
|
||
|
||
- [[sanctum]] — governance decision implementing futarchy with custom extensions
|
||
- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] — uses Autocrat v0.3 as base infrastructure
|
||
- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — demonstrates staged rollout friction
|