MetaDAO · v0.6.0
FUTARELBfJfQ8RDGhg1wdhddq1odMAJUePHFuBYfUxKq
Decoded and indexed
Methodology
Separate what a market implies from what it proves.
Start with the conditional comparison, then examine depth, trading behavior, participation and the governing rule. Each instrument states its evidence, assumptions and limitations.
Five questions, kept apart.
The market’s comparison answers the first. Each of the others needs its own evidence, and a later price alone settles none of them.
- 01What it implies
The conditional comparison between the choices, against the objective the market prices. A token-price difference is not automatically a change in enterprise value; a dollar figure needs a justified valuation and supply basis for each branch.
Read - 02Whether it passes
A separate outlook, published with its own forecast record or withheld. It is not a reliability probability for the comparison.
Forecast - 03Whether it executed
Whether the approved action was carried out, where a supported execution check and its evidence are available.
Checked - 04What followed
Measured horizons after the close, recorded as observations and never graded.
Observed - 05Whether it caused it
The unchosen branch is never observed, so a causal claim needs evidence beyond these observations.
Open
Test what supports the price.
Read how trading formed the comparison. The instruments run on supported conditional-swap records, not on every engine or decision, and a recorded reading is dated, not necessarily live.
Depth · flip cost v1.0.0
What moving the print costs
A scenario-dependent lower bound for moving one constant-product pool price from parity at disclosed or decoded depth. It excludes fees, opposing flow and the cost of holding the price through the time-weighted window; it is not a complete attack cost or safety rating.
Volume clock · order-flow toxicity v1.0.0
How one-sided the flow was
VPIN over supported indexed conditional swaps: up to 50 equal-volume buckets, the buy/sell split read from the chain rather than estimated, withheld under 40 trades. A decision market concludes one-sided, so a high reading is the shape of a market that decided — never an attack finding, and a low one never safety.
Signed flow · microstructure v1.0.0
Which way, and whether it accumulated
Order-flow imbalance at three horizons and the cumulative delta’s directness, signed from the chain’s own fills rather than inferred from price. Directness separates a steady build from two-way trading that ended in the same place.
Price impact
What a ticket moves
Kyle’s lambda, Amihud illiquidity, and a variance ratio, fitted per conditional pool on a window-derived clock and reported for the leg that moves most easily. Withheld rather than fitted where the fills are too sparse to sample.
Participation
Broad market, or one wallet
Wallet counts per side, concentration, two-sided interval share and volume before recording began help distinguish broad participation from a few accounts moving the price. They do not identify independent people or prove manipulation.
Declined
What a pool cannot answer
6 book-dependent measures are declined rather than approximated — effective and realized spread, markout, depth imbalance, the trade-based spread estimators, the longshot premium, self-counterparty wash. A constant-product pool has no bid, ask, queue or maker inventory, so each would be a number with no referent.
The rule
Every instrument reports its applicability and evidence coverage. An unavailable reading names the missing input. Any aggregate model would need a defined target and validation against a baseline.
What counts as a decision market
The record sorts every market by one rule. You can apply it yourself: each step says what to check.
- 01It decided something
Conditional markets priced an organization's own options, and the result decided or informed its choice. What “decided” means differs by engine; each engine's rule is below.
Decision - 02It drew 5 traders
Traders are the distinct wallets in a market's final trades, as the trade ledger records them. A market with fewer is left out by this rule, never by name; that is how test runs and untraded launches fall out. A market the ledger has no row for is not counted.
Floor - 03It belongs to one engine
An engine is an independent market mechanism. Launchpads and apps on an engine's rails are deployments: they count under that engine, never as one. Today: Futardio on MetaDAO, FairScale on Combinator, Star on Combinator, SurfCash on Combinator and Spark on Combinator. A decider is counted once on each engine it uses.
Engine - 04Six reviews, six findings
Evidence, Attack, Market, Playbooks, Learning and Claims each file their own finding on a decision: Filed, Withheld or Standing. No roster output approves a decision, proves causation, combines reviews into a composite score, or supplies a safety rating.
Reviews
Binding · Solana
MetaDAO
Counts when: The market passed or failed the proposal, and no administrator cancelled it. The 5 traders floor applies to the DAO account as a whole, not to each market.
Decider: The DAO account that put the proposal to the market.
Never counted: A DAO account that no tracked organization holds, once every decided window it ran has been read and none drew enough traders. An account not yet read stays in.
Mechanism: Pass or fail, judged on token value. Deployments on its rails: Futardio.
Binding · Solana
Combinator
Counts when: A version 1 market selected an option. The market drew at least 5 traders.
Decider: The moderator that ran the market.
Mechanism: Several options, judged on token value. Deployments on its rails: FairScale, Star, SurfCash and Spark.
Binding · Unichain
Butter
Counts when: The decision resolved and is valid. The market drew at least 5 traders.
Decider: The funder that deployed the decision.
Never counted: Butter's own markets. They demonstrate a choice that belongs to someone else.
Mechanism: Funding judged on a measured outcome.
Binding · Base
Umia
Counts when: The market settled. The market drew at least 5 traders.
Decider: The venture the market belongs to.
Mechanism: Several options, judged on token value.
Advisory · Gnosis Chain
Futarchy.fi
Counts when: The market selected an option. The market drew at least 5 traders.
Decider: The organization whose token the market prices, or the token itself where no organization is named.
Mechanism: Advisory prices beside a vote.
Binding and advisory
Binding: The market's result decides or selects the action. Advisory: The market's prices sit beside the organization's own vote, which is free to ignore them. The census counts both. Futarchy.fi is advisory; every figure splits by engine, so you can leave it out.
Which engine a program belongs toSeven governance programs, each assigned to its engine
MetaDAO · v0.5.0
auToUr3CQza3D4qreT6Std2MTomfzvrEeCC5qh7ivW5
Decoder pending: its decisions are not yet read
MetaDAO · proposal-duration-v0.4.2
autowMzCbM29YXMgVG3T62Hkgo7RcyrvgQQkd54fDQL
Decoder pending: its decisions are not yet read
MetaDAO · v0.3
autoQP9RmUNkzzKRXsMkWicDVZ3h29vvyMDcAYjCxxg
Decoder pending: its decisions are not yet read
MetaDAO · v0.2
metaRK9dUBnrAdZN6uUDKvxBVKW5pyCbPVmLtUZwtBp
Decoder pending: its decisions are not yet read
MetaDAO · v0.1
metaX99LHn3A7Gr7VAcCfXhpfocvpMpqQ3eyp3PGUUq
Decoder pending: its decisions are not yet read
MetaDAO · v0
meta3cxKzFBmWYgCVozmvCQAS3y9b3fGxrG9HkHL7Wi
Decoder pending: its decisions are not yet read
Seen, not countedMarkets that look like decision markets and are not
Seen, not counted
Shutter
Market-assisted grant selection; the organization approves payouts downstream.
Seen, not counted
Optimism Collective
Butter grants contest in play money.
Inspect the instruments behind each finding.
Each calculation has a version, its own evidence requirements and an explicit result. Partial evidence remains useful for the questions it can answer.
Disclosed terms
Which decision terms are present?
Trading participation
Who traded, and how concentrated was the observed volume?
Market reading
What do the observed prices imply under the selection rule?
Selection rule
Which disclosed terms affect how an option wins?
Closing stretch
Did the leader or implied outcome change near the close?
Earlier decisions
What had this decider selected before this window opened?
Measured outcome
What outcome did the resolver record?
Recycled-stake treasury extraction
A proposer acquires the required stake, rapidly recovers and reuses it in the decision market, with wallet-funding and execution behavior providing supporting evidence.
Late-window TWAP outcome steering
A trader waits out most of the TWAP window, then pushes a marginal print across its threshold in the closing stretch — when the required move is fully known and defenders have the least accrual time left to trade the price back. Late trades carry the least time-weight, so the target is a market already near its threshold, not the TWAP itself. Late activity also has benign forms — organic close-out and activist pressure — so a detector must separate steering from ordinary end-of-window trading.
Wash-volume alignment inflation
Automated near-neutral flow inflates a market's apparent volume and economic alignment, dressing thin conviction up as broad support while contributing no real position either way. The same fingerprint matches benign arbitrage flow, which published analysis strips as routine; a detector must separate deliberate wash from ordinary arb before it can say anything. So routine conditional arbitrage — one wallet's same-side legs on two options inside the cadence window — is netted out before any indicator is counted, and a wallet's presence on several options' markets counts only with same-pool round trips of at least the minimum turnover beside it. A market may have any number of options; pass and fail are the two of a pass/fail market. Machine cadence, frequency and tilt shift count only for wallets that show wash evidence — such round trips or a near-neutral ending — so a directional bot on a timer is not wash.
Coordinated multi-wallet stake assembly
An operator splits stake acquisition or market activity across coordinated wallets so no single address crosses the eligibility thresholds the organization enforces or the attribution thresholds a reviewer watches. Coordination alone is not an attack — multi-wallet holders and coordinated defenders share parts of this shape — so the mechanism is the threshold evasion, not the wallet count.
Historical review contractsRead earlier findings under their original definitions
Attack review · attack testingcontract v2.0.0
Try to break it.
The Attack review stress-tests the decision's disclosed selection rule, specification, delivery options, participation constraints, and branch dependencies, then runs versioned monitored playbooks against qualified evidence. Every classified result belongs to one mechanism, and no match is not a claim of safety. Documented threats remain sourced hypotheses with detector requirements: the Attack review may challenge them but never assess or classify them.
Contract · inputs, outputs, handoffQualified packet → Vector finding
Qualified packet
An Evidence-qualified packet: wallet history, funding path, accumulation, stake recovery, execution series, and the complete time-stamped semantics the market is asked to price. A qualified swap record feeds only the playbooks whose gates it fills; the rest stay withheld with their missing evidence named.
Vector finding
A semantic stress-test record plus, only for a monitored detector with complete evidence, a count of matched indicators and a classification scoped to that one vector; otherwise the state is explicitly withheld or documented-only.
Scoped result
A monitored finding travels with its vector id, version, and scope note. A documented threat travels as an unclassified candidate and evidence request. The Claims review checks both claim boundaries before publication.
Attack-vector library · 11 vectors4 monitored with a shipped detector · 7 documented
Economic governance attack · monitoredRecycled-stake treasury extraction
Economic governance attack · v1.0.2 · Monitored — detector shipped
Recycled-stake treasury extraction
A proposer acquires the required stake, rapidly recovers and reuses it in the decision market, with wallet-funding and execution behavior providing supporting evidence.
This classification is scoped to one monitored attack vector, not a validated composite proposal-risk score or a complete claim of safety.
Monitored indicators
01 · Identity context
Fresh wallet with no prior history
02 · Funding context
Cross-chain / bridge funding
03 · Eligibility acquisition
Accumulation trimmed to exact proposal-stake threshold
04 · Capital reuse
Stake recovered and reused in the decision market
05 · Market execution
Clustered fixed-size cadence trades
Published cases
Published case · 5 August 2026
Umbra
Evidence the detector consumes
01 · Required evidence
Wallet history: first activity and prior onchain record
02 · Required evidence
Funding path: venues and source chains for each leg
03 · Required evidence
Stake accumulation and trim relative to the required threshold
04 · Required evidence
Stake recovery latency and decision market reuse
05 · Required evidence
Trade execution series, or a published cadence summary
Decision market manipulation · monitoredLate-window TWAP outcome steering
Decision market manipulation · v3.0.0 · Monitored — detector shipped
Late-window TWAP outcome steering
A trader waits out most of the TWAP window, then pushes a marginal print across its threshold in the closing stretch — when the required move is fully known and defenders have the least accrual time left to trade the price back. Late trades carry the least time-weight, so the target is a market already near its threshold, not the TWAP itself. Late activity also has benign forms — organic close-out and activist pressure — so a detector must separate steering from ordinary end-of-window trading.
This classification is scoped to one monitored attack vector, not a validated composite proposal-risk score or a complete claim of safety.
Monitored indicators
01 · Timing
Aligned volume concentrated in the closing hours of the TWAP window
02 · Fragility
Printed outcome crosses the threshold on one marginal trade
03 · Liquidity
Closing move toward pass made with little money
04 · Reversal
The token's own price undoes the closing edge after the window
05 · Threshold pressure
Intra-window spike alone would clear the configured threshold
Evidence the detector consumes
01 · Required evidence
Indexed per-trade history with in-window timestamps and each pool's price
02 · Required evidence
TWAP window boundaries, the printed TWAPs and the threshold they were judged against
03 · Required evidence
The selected option and each pool's last price inside the window
04 · Required evidence
The token's ordinary dollar price in the hours after the close
Decision market manipulation · monitoredWash-volume alignment inflation
Decision market manipulation · v4.0.0 · Monitored — detector shipped
Wash-volume alignment inflation
Automated near-neutral flow inflates a market's apparent volume and economic alignment, dressing thin conviction up as broad support while contributing no real position either way. The same fingerprint matches benign arbitrage flow, which published analysis strips as routine; a detector must separate deliberate wash from ordinary arb before it can say anything. So routine conditional arbitrage — one wallet's same-side legs on two options inside the cadence window — is netted out before any indicator is counted, and a wallet's presence on several options' markets counts only with same-pool round trips of at least the minimum turnover beside it. A market may have any number of options; pass and fail are the two of a pass/fail market. Machine cadence, frequency and tilt shift count only for wallets that show wash evidence — such round trips or a near-neutral ending — so a directional bot on a timer is not wash.
This classification is scoped to one monitored attack vector, not a validated composite proposal-risk score or a complete claim of safety.
Monitored indicators
01 · Execution symmetry
Executions on more than one option's market from one wallet
02 · Cadence
Fixed-size trade clusters at machine cadence
03 · Exposure
Near-neutral ending exposure despite high turnover
04 · Frequency
Per-wallet trade frequency in the arbitrage band
05 · Alignment distortion
Net volume tilt moves materially once the flow is stripped
Evidence the detector consumes
01 · Required evidence
Wallet-attributed trade history across every option's market
02 · Required evidence
Ending exposure per wallet on each option
03 · Required evidence
Per-wallet trade frequency over the market's lifetime
04 · Required evidence
Volume tilt recomputed with the suspect flow removed
Economic governance attack · monitoredCoordinated multi-wallet stake assembly
Economic governance attack · v3.0.0 · Monitored — detector shipped
Coordinated multi-wallet stake assembly
An operator splits stake acquisition or market activity across coordinated wallets so no single address crosses the eligibility thresholds the organization enforces or the attribution thresholds a reviewer watches. Coordination alone is not an attack — multi-wallet holders and coordinated defenders share parts of this shape — so the mechanism is the threshold evasion, not the wallet count.
This classification is scoped to one monitored attack vector, not a validated composite proposal-risk score or a complete claim of safety.
Monitored indicators
01 · Funding context
Participating wallets linked by funding: one upstream source, or one funded by another
02 · Identity context
Wallets first active inside a tight shared window
03 · Eligibility acquisition
Combined position crosses a stake threshold no single wallet crosses
04 · Market execution
Matching trade-size and cadence fingerprint across wallets
05 · Exit behavior
Coordinated exit across the wallet set after resolution
Evidence the detector consumes
01 · Required evidence
Cross-wallet funding graph for the proposal window
02 · Required evidence
First-activity timestamps for each participating wallet
03 · Required evidence
Per-wallet positions measured against the stake requirement
04 · Required evidence
Per-wallet execution series for fingerprint comparison
Decision market manipulation · documentedTerminal-window TWAP capture
Decision market manipulation · v1.0.0 · Documented — detector pending
Terminal-window TWAP capture
A governance rule resolves on a TWAP measured over only a short terminal slice of a much longer decision period, on pools that need only clear a published minimum-liquidity floor. The entire resolving window is the closing stretch: the capital needed to own the print is calculable in advance from the floor and the window length, and defenders have no earlier accrual to lean on. Distinct from late-window outcome steering, which targets the tail of a full-length TWAP window — here the rule itself confines every unit of resolving weight to the terminal window. Genuine late information arrival produces the same late repricing, so a detector must separate engineered capture from honest end-of-period discovery.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Window structure
All resolving TWAP weight accrues in a terminal window that is a small fraction of the decision period
02 · Liquidity
Full-range depth sits at or barely above the published liquidity floor
03 · Timing
Markets stay quiet until the resolving window opens, then absorb concentrated aligned flow
04 · Fragility
Pass/fail ordering flips inside the resolving window after holding steady before it
05 · Reversal
Prices revert once the terminal window closes and weight stops accruing
Evidence a detector needs first
01 · Required evidence
The ratified rule: resolving-window length, liquidity floor, and pass condition as published
02 · Required evidence
Pool depth series across the decision period, with full-range liquidity measured against the floor
03 · Required evidence
Per-trade history with timestamps covering pre-window and in-window activity
04 · Required evidence
Post-resolution price series for reversion checks
Methodology sources
Governance-signal manipulation · documentedAdvisory-signal inflation
Governance-signal manipulation · v1.0.0 · Documented — detector pending
Advisory-signal inflation
Where a decision market is advisory — its price signal informs a vote or a bound delegate but executes nothing — moving the signal is cheap: no treasury settlement forces the manipulator to hold losing risk, and thin honest flow is the norm. An inflated print then travels as social proof through forums, delegates, and dashboards that cite the market as an endorsement. Honest participants also trade advisory markets at low volume, so a detector must separate manufactured endorsement from a thin but genuine signal.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Exposure
Directional prints arrive without exposure held through the signal read
02 · Capital sizing
Signal-moving flow is trivial against the decision's stated stakes
03 · Timing
Aligned flow concentrates just before the signal is read or a bound delegate executes
04 · Cross-check
Market signal diverges from the venue's own vote and forum alignment
05 · Reversal
Positions unwind once the advisory signal has been consumed
Evidence a detector needs first
01 · Required evidence
The advisory rule as published: what reads the signal, when, and at what threshold
02 · Required evidence
Wallet-attributed trade history across both conditional markets
03 · Required evidence
Timestamps of signal reads or bound-delegate executions against the flow series
04 · Required evidence
Position series after the signal is consumed, for unwind checks
Methodology sources
Proposal-priceability failure · documentedResistance-contingent delivery
Proposal-priceability failure · v1.0.0 · Documented — detector pending
Resistance-contingent delivery
A proposer leaves delivery discretionary, defends the pass/fail spread, and performs the promised work only when corrective trading makes continued price defense more expensive than delivery. The market can price the value of the promised work without pricing an enforceable obligation to perform it. This is a candidate mechanism from published threat-model research, not an observed attack finding.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Delivery terms
Proposal terms leave value-creating delivery at the proposer's discretion
02 · Market execution
Proposer-controlled pass-price defense appears before evidence of delivery
03 · Contingency
Delivery begins or improves only after corrective sell pressure rises
04 · Enforcement
Non-delivery carries no enforceable loss comparable with the proposal benefit
Evidence a detector needs first
01 · Required evidence
The proposal's signed delivery obligations, milestones, deadlines, and remedies for non-performance
02 · Required evidence
Wallet-attributed pass/fail executions and proposer funding paths across the decision window
03 · Required evidence
Timestamped delivery evidence measured against corrective market pressure
04 · Required evidence
Enforcement, escrow, slashing, or recovery records after missed obligations
Methodology sources
Proposal-priceability failure · documentedConditional holder-exit supply failure
Proposal-priceability failure · v1.0.0 · Documented — detector pending
Conditional holder-exit supply failure
Corrective pass-branch selling is constrained because a spot holder who sells is conditionally exiting the underlying asset, not merely opposing the proposal, while non-holders may lack short access and synthetic sellers bear adverse-selection risk. Mild proposal harm can therefore face less corrective supply than its holder base suggests. This is a candidate market-access mechanism, not evidence that a thin book was manipulated.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Participation access
Pass-branch sell flow is limited to existing holders willing to exit after passage
02 · Market access
Non-holders cannot create pass-branch short exposure
03 · Capital sizing
Corrective flow below the passage threshold is small against the proposer's private benefit
04 · Risk bearing
Withheld proposal information creates material adverse-selection risk for corrective sellers
Evidence a detector needs first
01 · Required evidence
Venue rules for minting, selling, borrowing, or shorting each conditional asset
02 · Required evidence
Holder-attributed pass-branch inventory and reserve-price or order-book depth across the decision window
03 · Required evidence
Synthetic short availability, collateral terms, borrow capacity, and observed utilization
04 · Required evidence
Proposal benefit, estimated holder harm, and corrective flow measured at the configured passage threshold
Methodology sources
Proposal-priceability failure · documentedProposal-convexity selection
Proposal-priceability failure · v1.0.0 · Documented — detector pending
Proposal-convexity selection
A proposer submits before material proposal-specific uncertainty resolves, so passage selects for favorable-information worlds and the pass price can exceed the fail price even when unconditional approval has negative expected value. The mechanism depends on an unsettled conditional-versus-causal argument and records that causal assumption rather than claiming proof.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Causal assumption
A material proposal-specific fact remains unresolved when the decision window opens
02 · Selection timing
The unresolved fact can become known before the market-guided decision executes
03 · Conditional selection
Favorable realizations are mechanically more likely to produce passage
04 · Value model
Conditional pass value and ex ante approval value diverge under disclosed assumptions
Evidence a detector needs first
01 · Required evidence
A pre-window inventory of material unresolved proposal facts and their disclosure timestamps
02 · Required evidence
The venue's decision, cancellation, and settlement rule, including any independent randomization
03 · Required evidence
A sourced ex ante value model with favorable and unfavorable proposal-specific branches kept separate
04 · Required evidence
Trade and decision timestamps sufficient to test whether information arrival and passage were coupled
Methodology sources
Proposal-priceability failure · documentedCountertrade adverse-selection deterrence
Proposal-priceability failure · v1.0.0 · Documented — detector pending
Countertrade adverse-selection deterrence
A proposer withholds value-relevant specification and buys pass exposure, while corrective traders hesitate because the missing terms might conceal either a harmful deal or favorable private information that makes selling costly. The resulting participation gap is a candidate proposal-specification threat, not a classification of every confidential proposal.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Proposal specification
Counterparty, scope, fees, milestones, or performance commitments are withheld
02 · Market execution
Proposer-linked wallets accumulate pass exposure while material terms remain hidden
03 · Adverse selection
Corrective sellers face larger losses in a plausible hidden-good state than gains in the visible bad state
04 · Disclosure timing
Value-relevant terms arrive only after corrective participation has been deterred
Evidence a detector needs first
01 · Required evidence
The complete proposal specification and a timestamped history of every material revision or disclosure
02 · Required evidence
Wallet attribution for proposer-linked pass/fail positions and their funding paths
03 · Required evidence
Order-book or execution evidence showing corrective participation before and after disclosure
04 · Required evidence
A sourced scenario analysis of losses to corrective sellers under hidden-good and hidden-bad terms
Methodology sources
Proposal-priceability failure · documentedFail-branch sabotage
Proposal-priceability failure · v1.0.0 · Documented — detector pending
Fail-branch sabotage
A proposer credibly commits to withdrawing support, liquidity, or another dependency if rejected, making the fail branch worse until accepting an otherwise harmful proposal becomes the locally higher-priced outcome. The candidate mechanism concerns branch independence and commitment, not proof that an observed fail discount was retaliation.
This vector is documented, not monitored: its detector has not shipped, so it never produces a classification. The definition records the mechanism and the evidence a detector would need first.
Defined indicators
01 · Branch independence
A proposer-controlled harm is explicitly or implicitly contingent on rejection
02 · Capability
The proposer controls a dependency capable of imposing the threatened harm
03 · Market response
The fail-branch discount appears with or strengthens after the threat
04 · Incentive
The proposer's off-path cost of carrying out the threat is smaller than the organization's loss
Evidence a detector needs first
01 · Required evidence
The proposal, communications, and contracts establishing any rejection-contingent action
02 · Required evidence
Evidence that the proposer controls the threatened dependency and can execute the harm
03 · Required evidence
Timestamped conditional-market prices around the threat's disclosure and credibility changes
04 · Required evidence
Sourced estimates of proposer cost, organization loss, legal recourse, and repeated-game penalties
Methodology sources
Saved data structure
Machine-readable library
The versioned vector definitions and team contracts ship as JSON — status, indicators, evidence requirements, methodology sources, case provenance, and boundaries.
Operating boundaries · contract v2.0.0Five limits on every Attack finding
Evidence review · evidence qualificationcontract v2.0.0
Qualify the evidence.
Before a decision gets a vector classification or priceability review, the Evidence review records what is present, what is missing, and how current it is. It qualifies disclosed specification, delivery terms, corrective access, and causal assumptions without filling gaps or deciding what those terms are worth.
Contract · inputs, outputs, handoffEvidence packet → Coverage state
Evidence packet
Wallet history, funding path, stake accumulation and recovery, trade execution, market data, a source-dated treasury snapshot, and the time-stamped disclosures of the decision's record — its options, selection rule, window, decider and terms — covering material facts, the disclosure cutoff, specification, delivery enforcement, participation access, branch dependencies, and causal assumptions. Where the decision's trades are recorded, the wallet-attributed swap record is qualified too, across every option's pool. For a launch-covenant record, the packet is the disclosed terms at issuance.
Coverage state
Availability, confidence, source freshness, field-level forensic coverage, disclosure qualification, a wallet-level census of an indexed swap record with the playbook gates it fills and the ones it cannot, and an explicit withheld state when required evidence is incomplete; a vector classification never runs without its own complete evidence gate.
Qualified record
Complete forensic evidence can move to monitored-vector matching; qualified proposal terms can move to priceability stress testing. Partial and unavailable packets keep their uncertainty attached for every downstream team.
Wallet historyFunding pathStake accumulationStake recoveryTrade evidence
Operating boundaries · contract v2.0.0Three limits on every Evidence finding
Playbooks review · playbook buildingcontract v2.0.0
Codify the research.
The Playbooks review turns published investigations into reusable definitions. A decision-priceability candidate gets a stable name, semver version, source, explicit assumptions, evidence requirements, indicators, and detector-pending status before any implementation exists; the incident or theory never becomes a classification.
Contract · inputs, outputs, handoffPublished research → Runnable definition
Published research
Cited decision records, market math, wallet forensics, explicit observations, theoretical mechanisms, counterarguments, and falsifiers from published source research.
Runnable definition
A versioned monitored mechanism with ordered indicators and an independent scope boundary, or a documented candidate with its detector evidence gate left visibly pending; covenant checks remain versioned against published launch terms. Against one decision, which monitored playbooks its evidence could run and what each other playbook still waits on.
Standing check
The Attack review receives runnable monitored playbooks and unclassified documented candidates. Published cases and theory remain provenance beneath them rather than hard-coded conclusions.
Attack playbooks4 monitored playbooks · 7 documented
Economic governance attack
Recycled-stake treasury extraction
v1.0.2 · monitored · 5 indicators · 1 published case
Decision market manipulation
Late-window TWAP outcome steering
v3.0.0 · monitored · 5 indicators · 0 published cases
Decision market manipulation
Wash-volume alignment inflation
v4.0.0 · monitored · 5 indicators · 0 published cases
Economic governance attack
Coordinated multi-wallet stake assembly
v3.0.0 · monitored · 5 indicators · 0 published cases
Decision market manipulation
Terminal-window TWAP capture
v1.0.0 · documented · 5 indicators · detector pending
Governance-signal manipulation
Advisory-signal inflation
v1.0.0 · documented · 5 indicators · detector pending
Proposal-priceability failure
Resistance-contingent delivery
v1.0.0 · documented · 4 indicators · detector pending
Proposal-priceability failure
Conditional holder-exit supply failure
v1.0.0 · documented · 4 indicators · detector pending
Proposal-priceability failure
Proposal-convexity selection
v1.0.0 · documented · 4 indicators · detector pending
Proposal-priceability failure
Countertrade adverse-selection deterrence
v1.0.0 · documented · 4 indicators · detector pending
Proposal-priceability failure
Fail-branch sabotage
v1.0.0 · documented · 4 indicators · detector pending
Covenant checks6 versioned against published STAMP terms
Covenant check
Use of proceeds restricted
v1.0.0 · Funds can only be used for product development and operating expenses.
Covenant check
Investor reserve capped and non-dilutable
v1.0.0 · Investor reserve at most 20% of total organization tokens and not dilutable post-agreement.
Covenant check
Team allocation in band with milestone vesting
v1.0.0 · Team allocation between 10% and 40% of total supply on milestone-based vesting.
Covenant check
Linear unlock schedule
v1.0.0 · Tokens enter a 24-month linear unlock once the Delivery Notice is received.
Covenant check
Cayman SPC/SP entity created
v1.0.0 · Founders create a Cayman SPC/SP entity through the venue interface.
Covenant check
Third-party review commissioned
v1.0.0 · A third-party review of the covenant or programs exists. STAMP itself requires none, so absence is the venue default, not a violation.
Operating boundaries · contract v2.0.0Three limits on every Playbooks finding
Claims review · claim controlcontract v2.0.0
Keep claims honest.
The Claims review checks the boundary around every published conclusion: what was measured, which vector it belongs to, whether evidence was complete, which causal assumptions remain unsettled, and what the result cannot establish. It refuses to turn six review findings into approval, causal proof, a composite score, or a safety rating.
Contract · inputs, outputs, handoffDraft findings → Publishable claims
Draft findings
Every team’s finding with its evidence state, vector scope, data vintage, decision terms, causal assumptions, and documented-versus-monitored status attached.
Publishable claims
Claims trimmed to what the evidence establishes, with withheld states and detector-pending threats explicit rather than rounded into approval, causal proof, or safety; against one decision, the vectors measured, their scope, and how many said nothing.
Published record
Only scoped, cited, per-review claims reach the page; approval, causal-proof, composite, and safety language goes back to the team that made it.
Claim statesVector matches, withheld states and covenant terms
HIGH-RISKELEVATEDWATCHNO-MATCH
Count-based matches for one complete, named attack vector. They are not a composite decision-risk score.
UNSCOREDUNKNOWNSTALEUNDER_REVIEW
Evidence or review state prevents a vector conclusion. Uncertainty remains explicit.
presentabsentunknown
Tri-state, fail-closed review of a launch covenant's disclosed terms. Unknown never rounds to present, and a covenant review is not a decision classification.
Operating boundaries · contract v2.0.0Four limits on every Claims finding
Market review · market watchcontract v2.0.0
Watch the market.
The Market review reads the decision's state, each option's time-weighted price, the engine's selection rule — a default option that stands unless a challenger beats it by a threshold, or a measured outcome read after the window — and observable access to corrective exposure. It describes decision fragility and participation constraints as market structure; its observations stay separate from the Attack review’s forensic result.
Contract · inputs, outputs, handoffDecision record → Threshold read
Decision record
The engine's own accounts and decision record provide current state, the selection rule and threshold, each option's time-weighted price, and, for a measured-outcome market, the outcome measured; retained reads place prices in the window, and venue rules and live depth describe who can supply corrective exposure. Where a decision's swaps are indexed, that public event record supplies the signed order flow, and it states how much of the window it reaches.
Threshold read
Under a price rule the best challenger's time-weighted price must strictly beat the default's by the threshold; a pass/fail market is the two-option case. Retained reads report the margin, crossings, closing-stretch pressure, an outlook while the window is open, corrective access, and disclosed-depth flip cost; a closed decision reports its completed print, and a measured-outcome market the outcome it was decided on; an indexed swap record additionally reports order-flow toxicity, signed imbalance, cumulative delta, per-pool price impact, and participation structure, each separately. Live math stays provisional; after settlement, the tape sits beneath the engine’s authoritative outcome.
Defense watch
Market state, corrective access, and decision fragility travel beside forensic context without standing in for missing wallet history, volume, execution evidence, or causal attribution.
Live surface
Open live markets Confirmed Futarchy activity
Inspect pending markets, funded drafts, decision-specific thresholds, and current pass/fail TWAPs.
Operating boundaries · contract v2.0.0Eight limits on every Market finding
Learning review · learning loopcontract v2.0.0
Close the loop.
The Learning review links what the Attack review learned in published cases with what the Market review should watch next. For decision-priceability candidates it retains disclosed assumptions, observed outcomes, sanctions, delivery, and falsifiers while keeping unobserved branches explicitly unobserved.
Contract · inputs, outputs, handoffClosed cases → Standing checks
Closed cases
Published incidents and experiments with their evidence, market outcome, delivery record, falsifiers, and vector result preserved together as cited replays.
Standing checks
Reusable, versioned checks and documented-candidate evidence updates extracted from observed outcomes, with unresolved and counterfactual outcomes kept out. Against one decision, what the same decider's earlier decisions on its engine selected, counting only those that closed before it opened, cited to the engine's record.
Refreshed watch
The Market and Attack reviews receive the updated check and its falsifiers; the old case keeps its citation, observed branches, and uncertainty as a replay.
Learning loopThree steps from an incident to a standing check
- 01
Preserve the incident
Keep the decision, source, evidence, market outcome, and vector result together as a cited replay.
- 02
Extract the mechanism
Separate reusable indicators from organization names and one-off narrative details.
- 03
Return it to watch
Give future decision reviews the versioned check while requiring their own evidence and market state.
Operational memory
Browse decision cases Published decision cases
Review the source-linked cases that produced reusable checks.
Operating boundaries · contract v2.0.0Three limits on every Learning finding
Add your organization's side of the record.
Every organization is on the record whether it answers or not. Beside what the chain shows, state what it cannot: what a decision is for, who it binds, what you committed to, and the documents behind it, checked and dated.