{ "schema": "tn12-covenant-experiment-map/v1", "network": "kaspa-testnet-12", "status": "experiment-map-ready", "generatedAt": "2026-05-13T04:28:49.072Z", "summary": { "experiments": 6, "spotlight": 3, "buildFirst": 0, "blockedBeforeLiveSubmit": 0, "genesisFundingDrafts": 0, "localProofs": 0, "acceptedGenesisPreflights": 0, "scriptEnforcedClaims": 5 }, "rule": "Each experiment must say what is accepted on TN12, what is script-enforced, what is wallet-policy, and what is only reducer/indexer state.", "spotlight": [ "blitz-mux-arena", "treasury-wars", "covenant-owned-asset-game" ], "experiments": [ { "id": "treasury-wars", "title": "Budget that cannot drain at once", "rank": 2, "status": "accepted-window-reset-proof", "proofTarget": "two accepted recurring-vault spends, accepted reset-window spend, continuation state, blocked over-cap and stale-window attempts", "whyItMatters": "Turns the active recurring cap rail into a simple strategy loop: each player has money, a cap window, allowed destinations, and relocked state.", "plainPoint": "Money can move automatically within a budget, then the budget can reopen in a new window without giving one operator full discretion.", "technicalPoint": "Stateful covenant outputs carry spent-in-window and window state forward, while reset_window enforces owner signature, cap, required destination, window age, and relocked continuation.", "kaspaEdge": "Fast UTXO confirmation makes chained state transitions practical enough for recurring budgets, games, and payment rails.", "cryptoPoint": "A server can track limits, but this shows the spend itself refusing the invalid path before the money moves.", "realWorldImplication": "Allowance wallets, team treasuries, merchant payout limits, grant streams, game resources, and parent/child budgets can use rules that travel with the funds.", "covenantPattern": "stateful singleton vault", "websitePitch": "Spend under a visible limit, lock the remaining money back into the rule, and block the move that tries to drain too much.", "currentRepoEvidence": [ "contracts/RecurringTreasuryVault.sil", "contracts/RecurringTreasuryVaultWindow.sil", "artifacts/recurring-treasury-vault-status.json", "artifacts/treasury-recurring-caps.json", "artifacts/recurring-treasury-vault-owner-sig-proof.json", "artifacts/recurring-treasury-vault-live-submit-readiness.json", "artifacts/recurring-treasury-vault-rust-submit-route-probe.json", "artifacts/recurring-treasury-vault-live-spend-preflight.json", "artifacts/signed-drafts/recurring-treasury-vault-genesis-funding.json", "artifacts/signed-drafts/recurring-treasury-vault-live-spend.json", "artifacts/recurring-treasury-vault-live-spend-evidence.json", "fixtures/RecurringTreasuryVaultContinuationOutpoint.json", "artifacts/signed-drafts/recurring-treasury-vault-cumulative-spend.json", "artifacts/recurring-treasury-vault-cumulative-spend-evidence.json", "fixtures/RecurringTreasuryVaultCumulativeContinuationOutpoint.json", "artifacts/signed-drafts/recurring-treasury-vault-cumulative-over-cap.json", "artifacts/recurring-treasury-vault-cumulative-cap-proof.json", "artifacts/signed-drafts/recurring-treasury-vault-window-genesis-funding.json", "fixtures/RecurringTreasuryVaultWindowContractOutpoint.json", "artifacts/signed-drafts/recurring-treasury-vault-window-reset.json", "artifacts/recurring-treasury-vault-window-reset-evidence.json", "fixtures/RecurringTreasuryVaultWindowResetContinuationOutpoint.json", "artifacts/signed-drafts/recurring-treasury-vault-window-early-reset.json", "artifacts/signed-drafts/recurring-treasury-vault-window-stale-reset.json", "artifacts/signed-drafts/recurring-treasury-vault-window-over-cap-reset.json", "artifacts/recurring-treasury-vault-window-reset-proof.json", "artifacts/recurring-treasury-vault-window-post-reset-spend-evidence.json", "fixtures/RecurringTreasuryVaultWindowPostResetContinuationOutpoint.json", "artifacts/wallet-approval-summaries.json" ], "nextBuildSteps": [ "Connect the approval summary to a user-wallet handoff for the same path.", "Turn the visible track into an interactive local-wallet round.", "Keep user-wallet signing out of the claim until a wallet-standard handoff signs the same path." ], "hardBoundary": "The accepted TN12 spends prove cumulative under-cap behavior and a reset-window primitive. They do not yet prove user-wallet signing, audited custody, or production calendar accounting." }, { "id": "covenant-heist", "title": "Bad withdrawal checks", "rank": 4, "status": "local-heist-rejects-on-accepted-vault-rail", "proofTarget": "accepted recurring-vault rail plus local rejects for wrong signer, wrong destination, missing continuation, over cap, early reset, stale reset, and reset over cap", "whyItMatters": "Makes the adversarial side visible. The game is a vault attack/defense loop where the interesting evidence is what cannot be spent.", "plainPoint": "The useful story is not only 'the good spend works'; it is 'the obvious bad spends fail.'", "technicalPoint": "Each attempted attack maps to a concrete script, planner, wallet-policy, or reducer guard.", "kaspaEdge": "Fast feedback lets reviewers try many bad paths against covenant-shaped outputs without waiting through slow settlement cycles.", "cryptoPoint": "Bad-path refusal matters because users should not need to trust a web server to politely decline an invalid withdrawal.", "realWorldImplication": "This is how family wallets, company vaults, escrow apps, and games explain safety to normal users: show the rejected moves.", "covenantPattern": "guarded vault plus challenge rows", "websitePitch": "Try the wrong signer, wrong destination, stale window, over-cap spend, or missing relock. The bad withdrawal should fail.", "currentRepoEvidence": [ "artifacts/covenant-heist-evidence.json", "artifacts/recurring-treasury-vault-negative-map.json", "artifacts/recurring-treasury-vault-owner-sig-proof.json", "artifacts/recurring-treasury-vault-cumulative-cap-proof.json", "artifacts/recurring-treasury-vault-window-reset-proof.json", "scripts/build-recurring-treasury-vault-negatives.mjs", "scripts/build-covenant-heist-evidence.mjs", "tests/domain/recurring-treasury-vault-negatives.test.mjs", "tests/domain/covenant-heist-evidence.test.mjs" ], "nextBuildSteps": [ "Only attempt broadcast-rejected invalid rows if fresh expendable covenant outputs are available.", "Keep the row labels local until TN12 rejection evidence exists.", "Turn the visible section into an interactive local attempt picker." ], "hardBoundary": "The good recurring-vault rail is accepted on TN12. The heist rows are local script-engine rejects, not TN12 broadcast-rejected invalid transactions." }, { "id": "blitz-mux-arena", "title": "Step-by-step workflow that can recover", "rank": 1, "status": "accepted-timeout-settlement-with-local-challenges", "proofTarget": "hub routes to two workers, workers return to hub, timeout escape path, bad selector and too-early timeout blocked locally", "whyItMatters": "Smallest source-faithful demo of the chess architecture without building full chess. It makes fast multi-transaction state transitions feel natural.", "plainPoint": "A complex rule system can be split into small roles instead of one huge contract.", "technicalPoint": "A mux covenant routes state to a worker template, the worker returns state, and timeout returns a stuck pending state to a safe path.", "kaspaEdge": "High-frequency blocks make multi-transaction contract flows feel usable instead of painfully slow.", "cryptoPoint": "The rules are attached to spendable outputs, so a player cannot just ask a private game server to rewrite the state.", "realWorldImplication": "The same pattern can support disputes, turn-based games, staged approvals, service jobs, and workflows where one step chooses the next bounded role.", "covenantPattern": "mux / worker contract family", "websitePitch": "One step goes to one role, comes back with valid state, or returns through a timeout if it stalls.", "currentRepoEvidence": [ "contracts/BlitzMux.sil", "contracts/BlitzWorkerA.sil", "contracts/BlitzWorkerB.sil", "artifacts/blitz-mux-arena-proof.json", "artifacts/signed-drafts/blitz-mux-arena-genesis-funding.json", "fixtures/BlitzMuxArenaContractOutpoint.json", "artifacts/blitz-mux-family-artifacts.json", "artifacts/signed-drafts/blitz-mux-family-genesis-funding.json", "fixtures/BlitzMuxFamilyContractOutpoint.json", "artifacts/signed-drafts/blitz-mux-route-to-worker-a.json", "fixtures/BlitzWorkerARouteOutpoint.json", "artifacts/signed-drafts/blitz-mux-worker-a-return.json", "fixtures/BlitzMuxReturnedOutpoint.json", "artifacts/signed-drafts/blitz-mux-route-to-worker-a-timeout.json", "fixtures/BlitzWorkerATimeoutRouteOutpoint.json", "artifacts/signed-drafts/blitz-mux-worker-a-timeout.json", "fixtures/BlitzMuxTimeoutOutpoint.json", "artifacts/signed-drafts/blitz-mux-route-to-worker-b.json", "fixtures/BlitzWorkerBRouteOutpoint.json", "artifacts/signed-drafts/blitz-mux-worker-b-return.json", "fixtures/BlitzMuxWorkerBReturnedOutpoint.json", "artifacts/blitz-mux-live-flow-evidence.json", "artifacts/blitz-mux-challenge-settlement.json", "artifacts/wallet-approval-summaries.json", "docs/TOCCATA_SOURCE_NOTES.md", "/home/parker2017/michaelsutton-silverscript-chess/examples/chess/ARCHITECTURE.md", "/home/parker2017/michaelsutton-silverscript-chess/examples/chess/book/src/webinar_mux.md" ], "nextBuildSteps": [ "Connect the wallet-readable summary to an interactive review card.", "Add a compact challenge variant only if it proves a new refusal path.", "Keep full game rules out until the mux flow is easy to inspect." ], "hardBoundary": "The mux genesis, Worker A route/return, timeout route/return, and Worker B route/return spends are accepted on TN12. This proves mux/worker, timeout mechanics, and a bounded timeout-settlement row, not full game rules or production game settlement." }, { "id": "coordination-league", "title": "Group payment that releases or refunds", "rank": 4, "status": "accepted-covenant-release-and-refund-spends", "proofTarget": "three qualifying intendos, accepted pledge receipts, fresh covenant pledge outputs, accepted covenant release spends, accepted covenant refund spends on a separate fresh pledge set", "whyItMatters": "Directly maps the Stag Hunt talk into repo evidence: commit only when enough compatible commitments also exist.", "plainPoint": "People can coordinate around shared goals without one platform deciding who gets paid after the fact.", "technicalPoint": "Assurance pledges, coordination receipts, fresh covenant outputs, and replayed settlement rows separate release, refund, and threshold state.", "kaspaEdge": "Fast visible receipts make coordination feel closer to live group action than slow escrow paperwork.", "cryptoPoint": "The refund/release paths can be checked from public evidence rather than trusting a campaign operator's database.", "realWorldImplication": "Useful for group buys, local projects, grants, event deposits, clubs, and cooperative funding where failure refunds must be credible.", "covenantPattern": "assurance plus coordination receipts", "websitePitch": "People pledge to a shared objective. If enough compatible pledges appear, the release path opens; otherwise refund stays explicit.", "currentRepoEvidence": [ "artifacts/coordination-market-prototype.json", "artifacts/coordination-market-settlement-brief.json", "artifacts/coordination-market-evidence-dossier.json", "artifacts/coordination-covenant-settlement-target.json", "artifacts/signed-drafts/coordination-covenant-pledge-funding.json", "fixtures/CoordinationCovenantPledgeOutpoints.json", "artifacts/signed-drafts/coordination-covenant-release-spends.json", "artifacts/coordination-covenant-release-evidence.json", "artifacts/signed-drafts/coordination-covenant-daa-refund-pledge-funding.json", "fixtures/CoordinationCovenantDaaRefundPledgeOutpoints.json", "artifacts/signed-drafts/coordination-covenant-refund-spends.json", "artifacts/coordination-covenant-refund-evidence.json", "artifacts/batch-assurance-campaign.json", "artifacts/batch-assurance-custody-imports.json", "artifacts/batch-assurance-settlement-drafts.json", "fixtures/AcceptedOutputEvidence.json", "tests/domain/coordination-covenant-release-evidence.test.mjs", "tests/domain/coordination-covenant-refund-evidence.test.mjs", "tests/domain/coordination-market-evidence.test.mjs" ], "nextBuildSteps": [ "Add wallet approval summaries for the coordination covenant release path.", "Keep threshold selection replay-derived until a covenant, proof system, or protocol primitive verifies it." ], "hardBoundary": "Fresh AssurancePledge covenant outputs, three covenant release spends, and three covenant refund spends are accepted on TN12. Release and refund use separate fresh pledge sets because each individual pledge output can only take one branch. The threshold pack selection is still transparent replay/planner evidence, not private coordination, pooled custody, or protocol-level coordination." }, { "id": "covenant-owned-asset-game", "title": "Asset that moves only with its controller", "rank": 3, "status": "accepted-sibling-input-strike", "proofTarget": "asset UTXO owned by a covenant input through sibling-input authorization", "whyItMatters": "Demonstrates ICC: one covenant does not execute the other, but can accept its sibling input as authority.", "plainPoint": "An asset can move only when the right game or controller output is present in the same transaction.", "technicalPoint": "The asset covenant checks a sibling input covenant id as authority instead of nesting and executing that sibling's full script.", "kaspaEdge": "Parallel UTXO inputs make sibling authorization a natural way to compose small contracts without shared mutable state.", "cryptoPoint": "Ownership can be programmatic and portable: the asset follows transaction rules, not a platform account entry.", "realWorldImplication": "This points toward tickets, passes, game items, licenses, settlement rights, and app-owned assets that can move only under visible rules.", "covenantPattern": "ICC / covenant-owned asset", "websitePitch": "An asset can move only when the right controller input joins the same transaction.", "currentRepoEvidence": [ "contracts/CovenantOwnedAssetDuel.sil", "artifacts/CovenantOwnedAssetDuel.json", "artifacts/covenant-owned-asset-duel-proof.json", "artifacts/signed-drafts/covenant-owned-asset-duel-genesis-funding.json", "fixtures/CovenantOwnedAssetDuelContractOutpoint.json", "artifacts/signed-drafts/asset-duel-owner-marker-genesis.json", "fixtures/AssetDuelOwnerMarkerOutpoint.json", "artifacts/CovenantOwnedAssetDuelLive.json", "artifacts/covenant-owned-asset-duel-live-artifact.json", "artifacts/signed-drafts/covenant-owned-asset-duel-live-genesis-funding.json", "fixtures/CovenantOwnedAssetDuelLiveContractOutpoint.json", "artifacts/signed-drafts/covenant-owned-asset-duel-live-strike.json", "fixtures/CovenantOwnedAssetDuelStrikeOutpoint.json", "artifacts/covenant-owned-asset-duel-live-strike-evidence.json", "artifacts/covenant-owned-asset-duel-live-negative-evidence.json", "artifacts/sibling-input-discovery.json", "artifacts/wallet-approval-summaries.json", "docs/TOCCATA_SOURCE_NOTES.md", "/home/parker2017/michaelsutton-silverscript-chess/examples/chess/book/src/patterns.md" ], "nextBuildSteps": [ "Connect the wallet-readable summary to an interactive review card.", "Only attempt broadcast-rejected negative rows if there is a safe non-spending route.", "Add one more accepted strike from the continuation only if it proves a new state transition.", "Keep user-wallet signing out of the claim until the same path signs through wallet-standard handoff." ], "hardBoundary": "The owner-marker genesis, live asset-duel genesis, and sibling-authorized strike spend are accepted on TN12. Negative candidates use the same live ids locally and are not broadcast-rejection records." }, { "id": "scheduler-duel", "title": "Scheduled payout with replayable evidence", "rank": 6, "status": "accepted-covenant-payout-spend", "proofTarget": "accepted scheduler intent, accepted execution receipt, accepted executor bids, accepted covenant payout spend, and blocked stale/slow/duplicate rows", "whyItMatters": "Uses current scheduler evidence to show conditional actions without pretending they are autonomous custody.", "plainPoint": "A user can publish an intended action, and an executor can only promote it when replayed state says it is eligible.", "technicalPoint": "Scheduler intents, executor receipts, replay checks, stale-action guards, and a guarded payout covenant separate trigger eligibility from money movement.", "kaspaEdge": "Fast accepted receipts make conditional execution easier to monitor and less dependent on one always-online operator.", "cryptoPoint": "Public replay gives users a way to verify whether an action was eligible instead of trusting a private automation log.", "realWorldImplication": "Useful for subscriptions, payroll windows, tournament turns, alerts, recurring payouts, and any workflow where missed or stale actions are expensive.", "covenantPattern": "based-app scheduler with covenant settlement target", "websitePitch": "Publish a conditional payout, let executors compete, and release only when accepted evidence says the action is eligible.", "currentRepoEvidence": [ "artifacts/universal-scheduler-workbench.json", "artifacts/scheduler-covenant-settlement-target.json", "artifacts/scheduler-intent-registry.json", "artifacts/scheduler-covenant-binding.json", "artifacts/payload-scheduler-intent-pool-rebalance-001-evidence.json", "artifacts/payload-scheduler-execution-receipt-001-evidence.json", "artifacts/payload-scheduler-bid-fast-executor-001-evidence.json", "artifacts/tn12-scheduler-execution-payout-user-03-evidence.json", "contracts/SchedulerCovenantPayout.sil", "artifacts/SchedulerCovenantPayout.json", "artifacts/signed-drafts/scheduler-covenant-payout-genesis-funding.json", "fixtures/SchedulerCovenantPayoutOutpoint.json", "artifacts/signed-drafts/scheduler-covenant-payout-release.json", "artifacts/scheduler-covenant-payout-evidence.json", "artifacts/scheduler-covenant-payout-negative-evidence.json", "tests/domain/universal-scheduler-workbench.test.mjs" ], "nextBuildSteps": [ "Connect the accepted covenant payout to a wallet-readable approval summary.", "Keep wrong recipient, wrong amount, and wrong input-value local rejects attached to review.", "Keep protocol scheduler and autonomous custody claims out of public copy." ], "hardBoundary": "The scheduler payout money movement is now an accepted TN12 covenant spend with local payout rejects. Trigger eligibility, winning-bid selection, and stale/duplicate blocking remain replay/indexer-derived." } ] }