Compare commits
6 commits
2633b96afe
...
929ed4f0f3
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
929ed4f0f3 | ||
| e9a6e88d26 | |||
| e89fb80eac | |||
|
|
da3ad3975c | ||
|
|
b2d24029c7 | ||
|
|
bb014f47d2 |
20 changed files with 527 additions and 6 deletions
|
|
@ -91,6 +91,12 @@ FutureDAO's token migrator extends the unruggable ICO concept to community takeo
|
|||
|
||||
MetaDAO ICO platform processed 8 projects from April 2025 to January 2026, raising $25.6M against $390M in committed demand (15x oversubscription). Platform generated $57.3M in Assets Under Futarchy and $1.5M in fees from $300M trading volume. Individual project performance: Avici 21x peak/7x current, Omnipair 16x peak/5x current, Umbra 8x peak/3x current with $154M committed for $3M raise (51x oversubscription). Recent launches (Ranger, Solomon, Paystream, ZKLSOL, Loyal) show convergence toward lower volatility with maximum 30% drawdown from launch.
|
||||
|
||||
|
||||
### Additional Evidence (extend)
|
||||
*Source: [[2024-11-08-futardio-proposal-initiate-liquidity-farming-for-future-on-raydium]] | Added: 2026-03-15 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
FutureDAO's post-launch governance activity extends MetaDAO's role beyond initial fundraising to ongoing operational decisions. The Raydium farm proposal (passed 2024-11-11) shows futarchy governing routine treasury operations—liquidity incentive allocation, farming duration, and DeFi integration—not just existential launch decisions. This suggests MetaDAO-launched projects continue using futarchy for operational governance after the ICO completes, making MetaDAO infrastructure for continuous governance rather than just a launch platform.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "AIMD algorithm achieves provably fair and stable distributed resource allocation using only local congestion feedback"
|
||||
confidence: proven
|
||||
source: "Corless, King, Shorten, Wirth (SIAM 2016) - AIMD Dynamics and Distributed Resource Allocation"
|
||||
created: 2026-03-11
|
||||
secondary_domains: [mechanisms, collective-intelligence]
|
||||
---
|
||||
|
||||
# AIMD converges to fair resource allocation without global coordination through local congestion signals
|
||||
|
||||
Additive Increase Multiplicative Decrease (AIMD) is a distributed resource allocation algorithm that provably converges to fair and stable resource sharing among competing agents without requiring centralized control or global information. The algorithm operates through two simple rules: when no congestion is detected, increase resource usage additively (rate += α); when congestion is detected, decrease resource usage multiplicatively (rate *= β, where 0 < β < 1).
|
||||
|
||||
The SIAM monograph by Corless et al. demonstrates that AIMD is mathematically guaranteed to converge to equal sharing of available capacity regardless of the number of agents or parameter values. Each agent only needs to observe local congestion signals—no knowledge of other agents, total capacity, or system-wide state is required. This makes AIMD the most widely deployed distributed resource allocation mechanism, originally developed for TCP congestion control and now applicable to smart grid energy allocation, distributed computing, and other domains where multiple agents compete for shared resources.
|
||||
|
||||
The key insight is that AIMD doesn't require predicting load, modeling arrivals, or solving optimization problems. It reacts to observed system state through simple local rules and is guaranteed to find the fair allocation through the dynamics of the algorithm itself. The multiplicative decrease creates faster convergence than purely additive approaches, while the additive increase ensures fairness rather than proportional allocation.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Corless, King, Shorten, Wirth (2016) provide mathematical proofs of convergence and fairness properties
|
||||
- AIMD is the foundation of TCP congestion control, the most widely deployed distributed algorithm in existence
|
||||
- The algorithm works across heterogeneous domains: internet bandwidth, energy grids, computing resources
|
||||
- Convergence is guaranteed regardless of number of competing agents or their parameter choices
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[coordination mechanisms]]
|
||||
- [[optimal governance requires mixing mechanisms because different decisions have different manipulation risk profiles]]
|
||||
- [[collective intelligence requires diversity as a structural precondition not a moral preference]]
|
||||
- [[designing coordination rules is categorically different from designing coordination outcomes as nine intellectual traditions independently confirm]]
|
||||
|
||||
Topics:
|
||||
- domains/internet-finance/_map
|
||||
- core/mechanisms/_map
|
||||
- foundations/collective-intelligence/_map
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "AIMD provides principled autoscaling for systems with expensive compute and variable load by reacting to queue state rather than forecasting demand"
|
||||
confidence: experimental
|
||||
source: "Corless et al. (SIAM 2016) applied to Teleo pipeline architecture"
|
||||
created: 2026-03-11
|
||||
secondary_domains: [mechanisms, critical-systems]
|
||||
---
|
||||
|
||||
# AIMD scaling solves variable-load expensive-compute coordination without prediction
|
||||
|
||||
For systems with expensive computational operations and highly variable load—such as AI evaluation pipelines where extraction is cheap but evaluation is costly—AIMD provides a principled scaling algorithm that doesn't require demand forecasting or optimization modeling. The algorithm operates by observing queue state: when the evaluation queue is shrinking (no congestion), increase extraction workers by 1 per cycle; when the queue is growing (congestion detected), halve extraction workers.
|
||||
|
||||
This approach is particularly well-suited to scenarios where:
|
||||
1. Downstream operations (evaluation) are significantly more expensive than upstream operations (extraction)
|
||||
2. Load is unpredictable and varies substantially over time
|
||||
3. The cost of overprovisioning is high (wasted expensive compute)
|
||||
4. The cost of underprovisioning is manageable (slightly longer queue wait times)
|
||||
|
||||
The AIMD dynamics guarantee convergence to a stable operating point where extraction rate matches evaluation capacity, without requiring any prediction of future load, modeling of arrival patterns, or solution of optimization problems. The system self-regulates through observed congestion signals (queue growth/shrinkage) and simple local rules.
|
||||
|
||||
The multiplicative decrease (halving workers on congestion) provides rapid response to capacity constraints, while the additive increase (adding one worker when uncongested) provides gradual scaling that avoids overshooting. This asymmetry is critical: it's better to scale down too aggressively and scale up conservatively than vice versa when downstream compute is expensive.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Corless et al. (2016) prove AIMD convergence properties hold for general resource allocation problems beyond network bandwidth
|
||||
- The Teleo pipeline architecture exhibits the exact characteristics AIMD is designed for: cheap extraction, expensive evaluation, variable load
|
||||
- AIMD's "no prediction required" property eliminates the complexity and fragility of load forecasting models
|
||||
- The algorithm's proven stability guarantees mean it won't oscillate or diverge regardless of load patterns
|
||||
|
||||
## Challenges
|
||||
|
||||
This is an application of proven AIMD theory to a specific system architecture, but the actual performance in the Teleo pipeline context is untested. The claim that AIMD is "perfect for" this setting is theoretical—empirical validation would strengthen confidence from experimental to likely.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[aimd-converges-to-fair-resource-allocation-without-global-coordination-through-local-congestion-signals]] <!-- claim pending -->
|
||||
- [[coordination mechanisms]]
|
||||
- [[designing coordination rules is categorically different from designing coordination outcomes as nine intellectual traditions independently confirm]]
|
||||
|
||||
Topics:
|
||||
- domains/internet-finance/_map
|
||||
- core/mechanisms/_map
|
||||
- foundations/critical-systems/_map
|
||||
|
|
@ -40,6 +40,12 @@ Optimism futarchy achieved 430 active forecasters and 88.6% first-time governanc
|
|||
|
||||
Sanctum's Wonder proposal failure reveals a new friction: team conviction vs. market verdict on strategic pivots. The team had strong conviction ('I want to build the right introduction to crypto: the app we all deserve, but no one is building') backed by market comparables (Phantom $3B, Jupiter $1.7B, MetaMask $320M fees) and team track record (safeguarding $1B+, making futarchy fun). Yet futarchy rejected the proposal. The team reserved 'the right to change details of the prospective features or go-to-market if we deem it better for the product' but submitted the core decision to futarchy, suggesting uncertainty about whether futarchy should govern strategic direction or just treasury/operations. This creates a new adoption friction: uncertainty about futarchy's appropriate scope (operational vs. strategic decisions) and whether token markets can accurately price founder conviction and domain expertise on product strategy.
|
||||
|
||||
|
||||
### Additional Evidence (confirm)
|
||||
*Source: [[2024-11-08-futardio-proposal-initiate-liquidity-farming-for-future-on-raydium]] | Added: 2026-03-15 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
The FutureDAO Raydium farm proposal demonstrates proposal complexity as adoption friction. The proposal document runs ~1000 words explaining standard liquidity farming mechanics—CLMM pools, fee tiers, emission rates, farming periods—that would be routine treasury decisions in traditional governance. The need to educate voters on basic DeFi infrastructure before they can evaluate the proposal adds cognitive overhead that token voting or multisig execution would avoid. Even though the proposal passed, the documentation burden confirms that futarchy requires more context-setting than simpler governance mechanisms.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -37,6 +37,12 @@ The contrast with Ranger is instructive. Ranger's liquidation shows futarchy han
|
|||
- The subcommittee model introduces trusted roles that could recentralize power over time, undermining the trustless property that makes futarchy valuable
|
||||
- Since [[Ooki DAO proved that DAOs without legal wrappers face general partnership liability making entity structure a prerequisite for any futarchy-governed vehicle]], some of this scaffolding is legally required rather than a failure of market mechanisms
|
||||
|
||||
|
||||
### Additional Evidence (confirm)
|
||||
*Source: [[2024-11-08-futardio-proposal-initiate-liquidity-farming-for-future-on-raydium]] | Added: 2026-03-15 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
FutureDAO's proposal to establish a Raydium liquidity farm demonstrates futarchy-governed DAOs using standard DeFi infrastructure for treasury operations. The proposal follows Raydium's standardized template: 1% token allocation, 7-90 day farming period, CLMM pool architecture, and ~0.1 SOL operational costs. Rather than inventing novel market mechanisms for liquidity provision, FutureDAO adopts the same infrastructure any traditional project would use. The futarchy mechanism governed WHETHER to create the farm (proposal passed 2024-11-11), but the HOW defaulted entirely to Raydium's existing operational scaffolding.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "At 5-20 server scale, queueing theory threshold policies capture most benefit without algorithmic complexity"
|
||||
confidence: likely
|
||||
source: "van Leeuwaarden, Mathijsen, Sanders (SIAM Review 2018) - empirical validation of square-root staffing at moderate scale"
|
||||
created: 2026-03-11
|
||||
depends_on: ["square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays.md"]
|
||||
---
|
||||
|
||||
# Moderate-scale queueing systems benefit from simple threshold policies over sophisticated algorithms because square-root staffing captures most efficiency gains
|
||||
|
||||
For systems operating at moderate scale (5-20 servers), the mathematical properties of the Halfin-Whitt regime mean that simple threshold-based policies informed by queueing theory capture most of the available efficiency gains. Sophisticated dynamic algorithms add implementation complexity without proportional benefit at this scale.
|
||||
|
||||
The square-root staffing principle works empirically even for systems as small as 5-6 servers, which means the core economies-of-scale insight applies well below the asymptotic regime where the mathematical proofs strictly hold. This has direct implications for pipeline architecture: a system with 5-6 workers doesn't need complex autoscaling algorithms or machine learning-based load prediction.
|
||||
|
||||
## Evidence
|
||||
|
||||
The SIAM Review tutorial explicitly notes that "square-root safety staffing works empirically even for moderate-sized systems (5-20 servers)" and that "at our scale (5-6 workers), we're in the 'moderate system' range where square-root staffing still provides useful guidance."
|
||||
|
||||
The key takeaway from the tutorial: "we don't need sophisticated algorithms for a system this small. Simple threshold policies informed by queueing theory will capture most of the benefit."
|
||||
|
||||
## Practical Application
|
||||
|
||||
For Teleo pipeline architecture operating at 5-6 workers, this means:
|
||||
- Simple threshold-based autoscaling policies are sufficient
|
||||
- Complex predictive algorithms add cost without proportional benefit
|
||||
- The mathematical foundation (Halfin-Whitt regime) validates simple approaches at this scale
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays]]
|
||||
- domains/internet-finance/_map
|
||||
|
||||
Topics:
|
||||
- core/mechanisms/_map
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "Raydium's liquidity farming infrastructure has converged on standardized parameters that projects adopt for token launches"
|
||||
confidence: likely
|
||||
source: "FutureDAO Raydium farm proposal, 2024-11-08; Raydium documentation"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Raydium liquidity farming follows standard pattern of 1% token allocation, 7-90 day duration, and CLMM pool architecture
|
||||
|
||||
Raydium has established a standardized liquidity farming template that projects adopt when launching tokens. The FutureDAO proposal demonstrates this pattern: 1% of total token supply allocated as rewards, farming period between 7-90 days per platform guidelines, and Concentrated Liquidity Market Maker (CLMM) pool architecture.
|
||||
|
||||
The proposal specifies standard implementation steps: create CLMM pool for token-stablecoin pair, establish farm linked to the pool with defined emission rate and duration, and ongoing monitoring. Raydium offers four fee tiers (0.01%, 0.05%, 0.25%, 1%) that projects select based on token volatility and expected trading volume.
|
||||
|
||||
Operational costs are minimal—approximately 0.1 SOL for pool and farm creation according to Raydium documentation. This low barrier to entry combined with standardized parameters suggests Raydium has productized liquidity bootstrapping into a repeatable template that reduces decision complexity for new projects.
|
||||
|
||||
The standardization extends beyond technical parameters to expected outcomes: proposals cite "enhanced liquidity," "reduced slippage," and "community engagement" as the value proposition, indicating convergence on both mechanism and narrative.
|
||||
|
||||
## Evidence
|
||||
- FutureDAO proposal allocates exactly 1% of total $FUTURE supply for Raydium farm rewards
|
||||
- Raydium guidelines specify 7-90 day farming periods as standard range
|
||||
- CLMM pool creation costs ~0.1 SOL per Raydium documentation
|
||||
- Four standardized fee tiers: 0.01%, 0.05%, 0.25%, 1%
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]]
|
||||
- [[MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale]]
|
||||
|
||||
Topics:
|
||||
- domains/internet-finance/_map
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "Bursty arrival processes require more safety capacity than Poisson models predict, scaled by variance-to-mean ratio"
|
||||
confidence: proven
|
||||
source: "Whitt et al., 'Staffing a Service System with Non-Poisson Non-Stationary Arrivals', Cambridge Core, 2016"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Square-root staffing formula requires peakedness adjustment for non-Poisson arrivals because bursty processes need proportionally more safety capacity than the Poisson baseline predicts
|
||||
|
||||
The standard square-root staffing formula (workers = mean load + safety factor × √mean) assumes Poisson arrivals where variance equals mean. Real-world arrival processes violate this assumption through burstiness (arrivals clustered in time) or smoothness (arrivals more evenly distributed than random).
|
||||
|
||||
Whitt et al. extend the square-root staffing rule by introducing **peakedness** — the variance-to-mean ratio of the arrival process — as the key adjustment parameter. For bursty arrivals (peakedness > 1), systems require MORE safety capacity than Poisson models suggest. For smooth arrivals (peakedness < 1), systems need LESS.
|
||||
|
||||
The modified staffing formula adjusts the square-root safety margin by multiplying by the square root of peakedness. This correction is critical for non-stationary systems where arrival rates vary over time (daily cycles, seasonal patterns, or event-driven spikes).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Whitt et al. (2016) prove that peakedness — the variance-to-mean ratio — captures the essential non-Poisson behavior for staffing calculations
|
||||
- Standard Poisson assumption (variance = mean) fails empirically for bursty workloads like research paper dumps, product launches, or customer service spikes
|
||||
- Using constant staffing (fixed MAX_WORKERS) regardless of queue state creates dual failure: over-provisioning during quiet periods (wasted compute) and under-provisioning during bursts (queue explosion)
|
||||
|
||||
## Relevance to Pipeline Architecture
|
||||
|
||||
Teleo's research pipeline exhibits textbook non-Poisson non-stationary arrivals: research dumps arrive in bursts of 15+ sources, futardio launches come in waves of 20+ proposals, while other days see minimal activity. The peakedness parameter quantifies exactly how much extra capacity is needed beyond naive square-root staffing.
|
||||
|
||||
This directly informs dynamic worker scaling: measure empirical peakedness from historical arrival data, adjust safety capacity accordingly, and scale workers based on current queue depth rather than using fixed limits.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- domains/internet-finance/_map
|
||||
|
||||
Topics:
|
||||
- core/mechanisms/_map
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "The QED Halfin-Whitt regime shows server count n grows while utilization approaches 1 at rate Θ(1/√n)"
|
||||
confidence: proven
|
||||
source: "van Leeuwaarden, Mathijsen, Sanders (SIAM Review 2018) - Economies-of-Scale in Many-Server Queueing Systems"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Square-root staffing principle achieves economies of scale in queueing systems by operating near full utilization with manageable delays
|
||||
|
||||
The QED (Quality-and-Efficiency-Driven) Halfin-Whitt heavy-traffic regime provides the mathematical foundation for understanding economies of scale in multi-server systems. As server count n grows, the system can operate at utilization approaching 1 while maintaining bounded delays, with the key insight that excess capacity needs to grow only at rate Θ(1/√n) rather than linearly.
|
||||
|
||||
This "square root staffing" principle means larger systems need proportionally fewer excess servers for the same service quality. A system with 100 servers might need 10 excess servers for target service levels, while a system with 400 servers needs only 20 excess servers (not 40) for the same quality.
|
||||
|
||||
The regime applies across system sizes from tens to thousands of servers, and empirical validation shows the square-root safety staffing works even for moderate-sized systems in the 5-20 server range.
|
||||
|
||||
## Evidence
|
||||
|
||||
From the SIAM Review tutorial:
|
||||
- Mathematical proof that utilization approaches 1 at rate Θ(1/√n) as server count grows
|
||||
- Empirical validation showing square-root staffing works for systems as small as 5-20 servers
|
||||
- The regime connects abstract queueing theory to practical staffing decisions across industries
|
||||
|
||||
## Implications for Pipeline Architecture
|
||||
|
||||
For systems in the 5-6 worker range, sophisticated dynamic algorithms provide minimal benefit over simple threshold policies informed by queueing theory. The economies-of-scale result also indicates that marginal value per worker decreases as systems grow beyond 20+ workers, which is critical for cost optimization in scaled deployments.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- domains/internet-finance/_map
|
||||
|
||||
Topics:
|
||||
- core/mechanisms/_map
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "Replacing non-stationary arrival rates with constant staffing leads to systematic over- or under-provisioning"
|
||||
confidence: proven
|
||||
source: "Whitt et al., 'Staffing a Service System with Non-Poisson Non-Stationary Arrivals', Cambridge Core, 2016"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Time-varying arrival rates require dynamic staffing not constant MAX_WORKERS because using average or maximum rates as constants creates systematic misallocation across the arrival cycle
|
||||
|
||||
Non-stationary arrival processes — where the arrival rate itself changes over time — cannot be efficiently staffed with constant worker counts. Whitt et al. demonstrate that replacing time-varying rates with either the average rate or the maximum rate produces badly mis-staffed systems:
|
||||
|
||||
- **Constant = average rate**: Under-staffed during peak periods, leading to queue explosions and service degradation
|
||||
- **Constant = maximum rate**: Over-staffed during off-peak periods, wasting capacity and compute resources
|
||||
|
||||
The optimal approach tracks the arrival rate over time and adjusts staffing dynamically to match the current load plus an appropriate safety margin (scaled by peakedness for non-Poisson processes).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Whitt et al. (2016) prove that time-varying arrival rates require time-varying staffing levels for efficiency
|
||||
- Constant staffing at maximum capacity wastes resources during low-traffic periods
|
||||
- Constant staffing at average capacity fails catastrophically during burst periods
|
||||
- Dynamic staffing based on current queue state and arrival rate estimates achieves both efficiency (no waste during quiet periods) and reliability (adequate capacity during bursts)
|
||||
|
||||
## Application to Teleo Pipeline
|
||||
|
||||
Teleo's research processing pipeline exhibits strong non-stationarity: research dumps and futardio launches create burst periods with 15-20+ simultaneous arrivals, while other periods see minimal activity. Using a fixed MAX_WORKERS setting (constant staffing) is the worst of both worlds:
|
||||
|
||||
- During bursts: MAX_WORKERS is too low, queue explodes, processing stalls
|
||||
- During quiet periods: MAX_WORKERS is too high, workers sit idle, compute wasted
|
||||
|
||||
Dynamic worker scaling based on current queue depth and estimated arrival rate (with peakedness adjustment) is the theoretically correct solution.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[square-root-staffing-formula-requires-peakedness-adjustment-for-non-poisson-arrivals]]
|
||||
- domains/internet-finance/_map
|
||||
|
||||
Topics:
|
||||
- core/mechanisms/_map
|
||||
|
|
@ -48,6 +48,7 @@ MetaDAO's token launch platform. Implements "unruggable ICOs" — permissionless
|
|||
- **2026-03-04** — [[seekervault]] fundraise launched targeting $75,000, closed next day with only $1,186 (1.6% of target) in refunding status
|
||||
- **2026-03-05** — [[insert-coin-labs-futardio-fundraise]] launched for Web3 gaming studio (failed, $2,508 / $50K = 5% of target)
|
||||
- **2026-03-05** — [[git3-futardio-fundraise]] failed: Git3 raised $28,266 of $100K target (28.3%) before entering refunding status, demonstrating market filtering even with live MVP
|
||||
- **2024-11-08** — [[futuredao-initiate-liquidity-farming-raydium]] passed: FutureDAO allocates 1% of $FUTURE supply to Raydium liquidity farm (proposal #5)
|
||||
## Competitive Position
|
||||
- **Unique mechanism**: Only launch platform with futarchy-governed accountability and treasury return guarantees
|
||||
- **vs pump.fun**: pump.fun is memecoin launch (zero accountability, pure speculation). Futardio is ownership coin launch (futarchy governance, treasury enforcement). Different categories despite both being "launch platforms."
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
type: entity
|
||||
entity_type: decision_market
|
||||
name: "FutureDAO: Initiate Liquidity Farming for $FUTURE on Raydium"
|
||||
domain: internet-finance
|
||||
status: passed
|
||||
parent_entity: "[[futardio]]"
|
||||
platform: "futardio"
|
||||
proposer: "proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2"
|
||||
proposal_url: "https://www.futard.io/proposal/HiNWH2uKxjrmqZjn9mr8vWu5ytp2Nsz6qLsHWa5XQ1Vm"
|
||||
proposal_date: 2024-11-08
|
||||
resolution_date: 2024-11-11
|
||||
category: "treasury"
|
||||
summary: "Allocate 1% of $FUTURE supply to Raydium liquidity farm to bootstrap trading liquidity"
|
||||
tracked_by: rio
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# FutureDAO: Initiate Liquidity Farming for $FUTURE on Raydium
|
||||
|
||||
## Summary
|
||||
Proposal to establish a Raydium liquidity farm for $FUTURE token, allocating 1% of total supply as rewards to incentivize liquidity providers. The farm would use Raydium's CLMM (Concentrated Liquidity Market Maker) architecture with a $FUTURE-USDC pair, farming period of 7-90 days, and standard fee tier selection based on token volatility.
|
||||
|
||||
## Market Data
|
||||
- **Outcome:** Passed
|
||||
- **Proposer:** proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2
|
||||
- **Proposal Account:** HiNWH2uKxjrmqZjn9mr8vWu5ytp2Nsz6qLsHWa5XQ1Vm
|
||||
- **DAO Account:** ofvb3CPvEyRfD5az8PAqW6ATpPqVBeiB5zBnpPR5cgm
|
||||
- **Autocrat Version:** 0.3
|
||||
- **Proposal Number:** #5
|
||||
- **Created:** 2024-11-08
|
||||
- **Completed:** 2024-11-11
|
||||
|
||||
## Significance
|
||||
Demonstrates futarchy-governed DAOs using standard DeFi infrastructure for treasury operations rather than inventing novel mechanisms. The proposal follows Raydium's productized template (1% allocation, 7-90 day duration, CLMM pools, ~0.1 SOL costs), showing futarchy governing WHETHER to act while defaulting to traditional operational scaffolding for HOW to execute.
|
||||
|
||||
Also extends MetaDAO's role beyond launch platform to ongoing operational governance—FutureDAO continues using futarchy for routine treasury decisions post-ICO.
|
||||
|
||||
## Relationship to KB
|
||||
- [[futardio]] - parent entity, governance platform
|
||||
- [[raydium]] - DeFi infrastructure provider
|
||||
- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]] - confirms this pattern
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
{
|
||||
"raw_response": "```json\n{\n \"claims\": [],\n \"enrichments\": [],\n \"entities\": [\n {\n \"filename\": \"metadao-proposal-7.md\",\n \"domain\": \"internet-finance\",\n \"action\": \"create\",\n \"entity_type\": \"decision_market\",\n \"content\": \"---\\ntype: entity\\nentity_type: decision_market\\nname: \\\"MetaDAO: Proposal #7\\\"\\ndomain: internet-finance\\nstatus: failed\\nparent_entity: \\\"[[metadao]]\\\"\\nplatform: \\\"futardio\\\"\\nproposer: \\\"HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\\\"\\nproposal_url: \\\"https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\\\"\\nproposal_date: 2024-08-28\\nresolution_date: 2024-09-01\\ncategory: \\\"unknown\\\"\\nsummary: \\\"MetaDAO Proposal #7 failed after 4-day voting period with no proposal text or market data available\\\"\\ntracked_by: rio\\ncreated: 2026-03-11\\n---\\n\\n# MetaDAO: Proposal #7\\n\\n## Summary\\nProposal #7 on MetaDAO was created on 2024-08-28 and failed on 2024-09-01. No proposal text, rationale, or market data is available in the source archive. The proposal ran on Autocrat version 0.3.\\n\\n## Market Data\\n- **Outcome:** Failed\\n- **Proposer:** HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\\n- **Duration:** 4 days (2024-08-28 to 2024-09-01)\\n- **Platform:** Futardio\\n- **Autocrat Version:** 0.3\\n\\n## Significance\\nThis proposal represents an archival record of a failed MetaDAO governance decision. Without proposal content or market volume data, it serves primarily as a timeline marker in MetaDAO's governance history during the Autocrat v0.3 era.\\n\\n## Relationship to KB\\n- [[metadao]] - governance decision\\n- [[futardio]] - platform used\\n\",\n \"timeline_entry\": \"- **2024-08-28** \u2014 [[metadao-proposal-7]] failed: Proposal #7 rejected after 4-day voting period (no details available)\"\n }\n ],\n \"source_update\": {\n \"status\": \"processed\",\n \"processed_by\": \"rio\",\n \"processed_date\": \"2026-03-11\",\n \"claims_extracted\": [],\n \"enrichments_applied\": [],\n \"entities_updated\": [\"metadao-proposal-7.md\", \"metadao.md\"],\n \"key_facts\": [\n \"MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01\",\n \"Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\",\n \"DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce\",\n \"Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\",\n \"Autocrat version: 0.3\"\n ],\n \"notes\": \"Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed.\"\n }\n}\n```",
|
||||
"parsed": {
|
||||
"claims": [],
|
||||
"enrichments": [],
|
||||
"entities": [
|
||||
{
|
||||
"filename": "metadao-proposal-7.md",
|
||||
"domain": "internet-finance",
|
||||
"action": "create",
|
||||
"entity_type": "decision_market",
|
||||
"content": "---\ntype: entity\nentity_type: decision_market\nname: \"MetaDAO: Proposal #7\"\ndomain: internet-finance\nstatus: failed\nparent_entity: \"[[metadao]]\"\nplatform: \"futardio\"\nproposer: \"HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\"\nproposal_url: \"https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\"\nproposal_date: 2024-08-28\nresolution_date: 2024-09-01\ncategory: \"unknown\"\nsummary: \"MetaDAO Proposal #7 failed after 4-day voting period with no proposal text or market data available\"\ntracked_by: rio\ncreated: 2026-03-11\n---\n\n# MetaDAO: Proposal #7\n\n## Summary\nProposal #7 on MetaDAO was created on 2024-08-28 and failed on 2024-09-01. No proposal text, rationale, or market data is available in the source archive. The proposal ran on Autocrat version 0.3.\n\n## Market Data\n- **Outcome:** Failed\n- **Proposer:** HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\n- **Duration:** 4 days (2024-08-28 to 2024-09-01)\n- **Platform:** Futardio\n- **Autocrat Version:** 0.3\n\n## Significance\nThis proposal represents an archival record of a failed MetaDAO governance decision. Without proposal content or market volume data, it serves primarily as a timeline marker in MetaDAO's governance history during the Autocrat v0.3 era.\n\n## Relationship to KB\n- [[metadao]] - governance decision\n- [[futardio]] - platform used\n",
|
||||
"timeline_entry": "- **2024-08-28** \u2014 [[metadao-proposal-7]] failed: Proposal #7 rejected after 4-day voting period (no details available)"
|
||||
}
|
||||
],
|
||||
"source_update": {
|
||||
"status": "null-result",
|
||||
"processed_by": "rio",
|
||||
"processed_date": "2026-03-11",
|
||||
"claims_extracted": [],
|
||||
"enrichments_applied": [],
|
||||
"entities_updated": [
|
||||
"metadao-proposal-7.md",
|
||||
"metadao.md"
|
||||
],
|
||||
"key_facts": [
|
||||
"MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01",
|
||||
"Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6",
|
||||
"DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce",
|
||||
"Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc",
|
||||
"Autocrat version: 0.3"
|
||||
],
|
||||
"notes": "Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed.",
|
||||
"model": "anthropic/claude-sonnet-4.5"
|
||||
}
|
||||
},
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"date": "2026-03-15",
|
||||
"tokens": {
|
||||
"prompt_tokens": 11434,
|
||||
"completion_tokens": 1052,
|
||||
"total_tokens": 12486,
|
||||
"cost": 0.050082,
|
||||
"is_byok": false,
|
||||
"prompt_tokens_details": {
|
||||
"cached_tokens": 0,
|
||||
"cache_write_tokens": 0,
|
||||
"audio_tokens": 0,
|
||||
"video_tokens": 0
|
||||
},
|
||||
"cost_details": {
|
||||
"upstream_inference_cost": 0.050082,
|
||||
"upstream_inference_prompt_cost": 0.034302,
|
||||
"upstream_inference_completions_cost": 0.01578
|
||||
},
|
||||
"completion_tokens_details": {
|
||||
"reasoning_tokens": 0,
|
||||
"image_tokens": 0,
|
||||
"audio_tokens": 0
|
||||
}
|
||||
}
|
||||
}
|
||||
File diff suppressed because one or more lines are too long
|
|
@ -6,8 +6,13 @@ url: https://www.cambridge.org/core/journals/probability-in-the-engineering-and-
|
|||
date: 2016-01-01
|
||||
domain: internet-finance
|
||||
format: paper
|
||||
status: unprocessed
|
||||
status: processed
|
||||
tags: [pipeline-architecture, operations-research, stochastic-modeling, non-stationary-arrivals, capacity-sizing]
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted: ["square-root-staffing-formula-requires-peakedness-adjustment-for-non-poisson-arrivals.md", "time-varying-arrival-rates-require-dynamic-staffing-not-constant-max-workers.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Operations research paper on staffing under non-Poisson non-stationary arrivals. Extracted two claims on peakedness adjustment and dynamic staffing requirements. Direct application to Teleo pipeline architecture for worker scaling. No entity data (academic paper, no companies/products/decisions). No enrichments (novel theoretical contribution not covered by existing claims)."
|
||||
---
|
||||
|
||||
# Staffing a Service System with Non-Poisson Non-Stationary Arrivals
|
||||
|
|
|
|||
|
|
@ -6,8 +6,13 @@ url: https://epubs.siam.org/doi/book/10.1137/1.9781611974225
|
|||
date: 2016-01-01
|
||||
domain: internet-finance
|
||||
format: paper
|
||||
status: unprocessed
|
||||
status: processed
|
||||
tags: [pipeline-architecture, operations-research, AIMD, distributed-resource-allocation, congestion-control, fairness]
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted: ["aimd-converges-to-fair-resource-allocation-without-global-coordination-through-local-congestion-signals.md", "aimd-scaling-solves-variable-load-expensive-compute-coordination-without-prediction.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted two claims: (1) general AIMD mechanism properties as proven coordination algorithm, (2) specific application to Teleo pipeline architecture. The source is a formal mathematical treatment (SIAM monograph) providing rigorous proofs, making the first claim 'proven' confidence. The second claim is an application proposal with theoretical justification but no empirical validation, hence 'experimental'. No entities to extract—this is pure mechanism theory. No enrichments—AIMD is not currently referenced in the KB."
|
||||
---
|
||||
|
||||
# AIMD Dynamics and Distributed Resource Allocation
|
||||
|
|
@ -26,3 +31,10 @@ SIAM monograph on AIMD (Additive Increase Multiplicative Decrease) as a general-
|
|||
## Relevance to Teleo Pipeline
|
||||
|
||||
AIMD provides a principled, proven scaling algorithm: when eval queue is shrinking (no congestion), increase extraction workers by 1 per cycle. When eval queue is growing (congestion), halve extraction workers. This doesn't require predicting load, modeling arrivals, or solving optimization problems — it reacts to observed system state and is mathematically guaranteed to converge. Perfect for our "expensive compute, variable load" setting.
|
||||
|
||||
|
||||
## Key Facts
|
||||
- AIMD algorithm: additive increase (rate += α) when no congestion, multiplicative decrease (rate *= β, 0 < β < 1) when congestion detected
|
||||
- AIMD is the foundation of TCP congestion control
|
||||
- AIMD has been applied to internet congestion control, smart grid energy allocation, and distributed computing
|
||||
- AIMD convergence is mathematically proven regardless of number of agents or parameter values
|
||||
|
|
|
|||
|
|
@ -6,8 +6,13 @@ url: https://epubs.siam.org/doi/10.1137/17M1133944
|
|||
date: 2018-01-01
|
||||
domain: internet-finance
|
||||
format: paper
|
||||
status: unprocessed
|
||||
status: processed
|
||||
tags: [pipeline-architecture, operations-research, queueing-theory, Halfin-Whitt, economies-of-scale, square-root-staffing]
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted: ["square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays.md", "moderate-scale-queueing-systems-benefit-from-simple-threshold-policies-over-sophisticated-algorithms-because-square-root-staffing-captures-most-efficiency-gains.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted two claims about queueing theory and economies of scale. The source is a mathematical tutorial with proven results (SIAM Review), so confidence is 'proven' for the core mathematical claim and 'likely' for the practical application claim. No entities to extract (academic paper, no companies/products/decisions). The relevance to Teleo is in pipeline architecture optimization, which is noted in the source's 'Relevance to Teleo Pipeline' section."
|
||||
---
|
||||
|
||||
# Economies-of-Scale in Many-Server Queueing Systems
|
||||
|
|
@ -26,3 +31,9 @@ SIAM Review tutorial on the QED (Quality-and-Efficiency-Driven) Halfin-Whitt hea
|
|||
## Relevance to Teleo Pipeline
|
||||
|
||||
At our scale (5-6 workers), we're in the "moderate system" range where square-root staffing still provides useful guidance. The key takeaway: we don't need sophisticated algorithms for a system this small. Simple threshold policies informed by queueing theory will capture most of the benefit. The economies-of-scale result also tells us that if we grow to 20+ workers, the marginal value of each additional worker decreases — important for cost optimization.
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Halfin-Whitt QED regime: utilization approaches 1 at rate Θ(1/√n)
|
||||
- Square-root staffing validated empirically for systems as small as 5-20 servers
|
||||
- 100-server system needs ~10 excess servers; 400-server system needs ~20 (not 40) for same quality
|
||||
|
|
|
|||
|
|
@ -6,13 +6,17 @@ url: "https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2024-08-28
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. The source provides verifiable facts (proposal number, accounts, dates, status) but no evidence supporting arguable claims about futarchy mechanisms, governance outcomes, or market behavior. Without proposal content or outcome analysis, there is nothing to extract as claims or enrichments. The existing claim 'MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions' could potentially be enriched if this proposal had volume data, but none is provided. This is purely archival metadata."
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -39,3 +43,11 @@ extraction_notes: "This source contains only metadata about a failed MetaDAO pro
|
|||
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
||||
- Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc
|
||||
- Autocrat version: 0.3
|
||||
|
||||
|
||||
## Key Facts
|
||||
- MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01
|
||||
- Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6
|
||||
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
||||
- Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc
|
||||
- Autocrat version: 0.3
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HiNWH2uKxjrmqZjn9mr8vWu5ytp2Nsz6qLsHWa5XQ1V
|
|||
date: 2024-11-08
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: processed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
@ -14,6 +14,12 @@ processed_date: 2024-11-08
|
|||
enrichments_applied: ["futarchy-governed-DAOs-converge-on-traditional-corporate-governance-scaffolding-for-treasury-operations-because-market-mechanisms-alone-cannot-provide-operational-security-and-legal-compliance.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md", "futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted one new claim about Raydium's standard liquidity farming pattern (1% allocation, 7-90 day duration, CLMM architecture). Identified three enrichments: confirms futarchy DAOs use traditional DeFi infrastructure for operations, extends MetaDAO's role to post-launch governance, and confirms proposal complexity as adoption friction. Source demonstrates futarchy governing routine treasury operations, not just existential decisions."
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted: ["raydium-liquidity-farming-follows-standard-pattern-of-1-percent-token-allocation-7-to-90-day-duration-and-clmm-pool-architecture.md"]
|
||||
enrichments_applied: ["futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance.md", "MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale.md", "futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted one new claim about Raydium's standard liquidity farming pattern (1% allocation, 7-90 day duration, CLMM architecture). Identified three enrichments: confirms futarchy DAOs use traditional DeFi infrastructure for operations, extends MetaDAO's role to post-launch governance, and confirms proposal complexity as adoption friction. Created decision_market entity for the proposal and company entity for Raydium. Source demonstrates futarchy governing routine treasury operations, not just existential decisions."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -105,3 +111,11 @@ Establishing a Raydium farm for \$FUTURE with 1% of the total supply as rewards
|
|||
- Raydium offers fee tiers of 0.01%, 0.05%, 0.25%, and 1%
|
||||
- FutureDAO is proposal #5 on DAO account ofvb3CPvEyRfD5az8PAqW6ATpPqVBeiB5zBnpPR5cgm
|
||||
- Proposal used Autocrat version 0.3
|
||||
|
||||
|
||||
## Key Facts
|
||||
- FutureDAO proposal HiNWH2uKxjrmqZjn9mr8vWu5ytp2Nsz6qLsHWa5XQ1Vm passed 2024-11-11
|
||||
- Raydium CLMM pool creation costs approximately 0.1 SOL
|
||||
- Raydium offers fee tiers of 0.01%, 0.05%, 0.25%, and 1%
|
||||
- FutureDAO is proposal #5 on DAO account ofvb3CPvEyRfD5az8PAqW6ATpPqVBeiB5zBnpPR5cgm
|
||||
- Proposal used Autocrat version 0.3
|
||||
|
|
|
|||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/6LcxhHS3JvDtbS1GoQS18EgH5Pzf7AnqQpR7D4HxmWp
|
|||
date: 2024-11-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-11
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Source is a futarchy governance proposal for Coal token emission schedule. Extracted as decision_market entity (the proposal itself) and created parent entity for Coal project. No novel claims about futarchy mechanisms - this is a straightforward application of existing governance patterns. The shift from algorithmic to market-driven emission control is notable but represents implementation of known futarchy principles rather than new mechanism insight."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -66,3 +70,10 @@ A follow-up decision market will be held in early January, approximately two mon
|
|||
- Autocrat version: 0.3
|
||||
- Completed: 2024-11-17
|
||||
- Ended: 2024-11-17
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Coal token emission rate reduced from 15.625 to 7.8125 per minute (2024-11-17)
|
||||
- Coal annual inflation reduced from ~110% to ~56% (2024-11-17)
|
||||
- Coal completed 6 halvings before governance transition
|
||||
- Coal proposal 6LcxhHS3JvDtbS1GoQS18EgH5Pzf7AnqQpR7D4HxmWpy passed (2024-11-17)
|
||||
|
|
|
|||
Loading…
Reference in a new issue