Qualified packet
A Pink-qualified packet: wallet history, funding path, accumulation, stake recovery, execution series, and the complete time-stamped semantics the proposer asks the market to price.
Color Teams · six specialist teams
One proposal.Every angle.
One shared evidence layer, six bounded lines of inquiry. Each team returns its own finding so certainty in one lane cannot hide uncertainty in another.
6bounded reviews
1evidence layer
0composite scores
Red Team · attack testingcontract v1.1.0
Try to break it.
The Red Team stress-tests proposer-controlled 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: Red may challenge them but never assess or classify them.
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 White Team checks both claim boundaries before publication.
Attack-vector library · 11 dossiers
Choose a vector
Show one vector at a time. Monitored vectors have a shipped detector; documented vectors stay non-classifying until their detector ships.
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 · v2.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
Price move outsized against posted depth near the threshold
04 · Reversal
Price snaps back once TWAP weight stops accruing
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
02 · Required evidence
TWAP window boundaries and per-trade accrued weight
03 · Required evidence
Depth series around the configured threshold
04 · Required evidence
Post-finalization price series for snap-back checks
Decision-market manipulation · v2.0.1 · 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.
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
Paired pass-market and fail-market executions 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 both conditional markets
02 · Required evidence
Ending pass/fail exposure per wallet
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 · v2.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 protocol 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 funded from one upstream source
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 · 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 · 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 · 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 · 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 · 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 · 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 · 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.
Pink Team · evidence qualificationcontract v1.2.0
Qualify the evidence.
Before a proposal gets a vector classification or priceability review, the Pink Team 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.
Evidence packet
Wallet history, funding path, stake accumulation and recovery, trade execution, market data, a source-dated treasury snapshot, and time-stamped proposal disclosures covering material facts, the disclosure cutoff, specification, delivery enforcement, participation access, branch dependencies, and causal assumptions. 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, 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
Yellow Team · playbook buildingcontract v1.2.0
Codify the research.
The Yellow Team turns published investigations into reusable definitions. A proposal-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.
Published intelligence
Cited proposal 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.
Standing check
The Red Team 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
v2.0.0 · monitored · 5 indicators · 0 published cases
Decision-market manipulation
Wash-volume alignment inflation
v2.0.1 · monitored · 5 indicators · 0 published cases
Economic governance attack
Coordinated multi-wallet stake assembly
v2.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 project 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.
White Team · claim controlcontract v1.2.0
Keep claims honest.
The White Team 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 lane findings into approval, causal proof, a composite score, or a safety rating.
Draft findings
Every team’s finding with its evidence state, vector scope, data vintage, proposal 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.
Published record
Only scoped, cited, per-lane claims reach the page; approval, causal-proof, composite, and safety language goes back to the team that made it.
HIGH-RISKELEVATEDWATCHNO-MATCH
Count-based matches for one complete, named attack vector. They are not a composite proposal-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 proposal classification.
Blue Team · market watchcontract v1.5.0
Watch the market.
The Blue Team reads confirmed proposal state, pass-market and fail-market TWAPs, the DAO’s configured threshold, and observable access to corrective pass/fail exposure. It describes decision fragility and participation constraints as market structure; its observations stay separate from the Red Team’s forensic result.
Confirmed accounts
Futarchy proposal and DAO accounts provide current state, proposal class, the configured threshold, and pass/fail TWAP accumulators; venue rules and live depth describe who can supply corrective exposure. Where a proposal's conditional swaps are indexed, that public event record supplies the signed order flow, and it states how much of the window it reaches.
Threshold read
The pass-market TWAP must beat the configured threshold over the fail-market TWAP. Retained reads report margin, crossings, closing-stretch pressure, corrective access, and disclosed-depth flip cost; 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 account’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, proposal-specific thresholds, and current pass/fail TWAPs.
InstrumentsFlip-cost scenario v1.0.0 · Order-flow toxicity v1.0.0 · Microstructure v1.0.0
Lower bound
What moving the print costs
The floor on pushing one conditional pool's print past its threshold at disclosed depth, published with its assumptions attached — a floor rather than a cost, and never a safety rating.
Volume clock
How one-sided the flow was
VPIN over the proposal's indexed conditional swaps: 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
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. VPIN takes an absolute value; these keep the direction, and 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.
Whose print
Broad market, or one wallet
Wallet counts per side, concentration, two-sided interval share, and the volume that printed before the TWAP window opened — reported separately and never folded into a credibility index, because a composite hides which input moved.
Refused
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. These are constant-product pools with no bid, ask, queue, or maker inventory, so each would be a number with no referent. An information-leakage score is declined too: every timestamp the account carries is a moment the market learned.
Purple Team · learning loopcontract v1.1.0
Close the loop.
The Purple Team links what the Red Team learned in published cases with what the Blue Team should watch next. For proposal-priceability candidates it retains disclosed assumptions, observed outcomes, sanctions, delivery, and falsifiers while keeping unobserved branches explicitly unobserved.
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.
Refreshed watch
The Blue Team and Red Team receive the updated check and its falsifiers; the old case keeps its citation, observed branches, and uncertainty as a replay.
- 01
Preserve the incident
Keep the proposal, source, evidence, market outcome, and vector result together as a cited replay.
- 02
Extract the mechanism
Separate reusable indicators from project names and one-off narrative details.
- 03
Return it to watch
Give future proposal reviews the versioned check while requiring their own evidence and market state.
Operational memory
Browse proposal cases Published proposal cases
Review the source-linked cases that produced reusable checks.