Spend from a budget, move an asset, release a group payment, recover a stalled step, or execute a scheduled payout.
Kaspa TN12 covenant proof lab. Testnet only.
Rules attached to testnet money.
This page tracks experiments where spendable outputs carry rules. Some paths landed on TN12. Some bad paths were rejected locally. Replay artifacts explain accepted state.
Spend-rule workbench
Check what each example makes the wallet approve.
Ignore the contract label. Check whether the user action produces four things: an accepted txid, a spend rule, replayed state, and a wallet prompt that explains pass or fail.
TN12 ordering
Accepted transaction lands in the testnet record.
Spend trail
The input is consumed and the next output must preserve the rule.
Rule ledger
- Expected
- under cap
- Observed
- accepted
- Boundary
- TN12 only
Accepted and rejected paths stay visible together.
Wallet prompt
Show the reason before signing.
Amount, controller input, continuation, timeout, refund, or blocker.
UTXOs, controller inputs, continuation outputs, app receipts, or pledge outputs become the thing being checked.
The rule may be script-enforced, wallet policy, replay-derived, or local-only. The label changes what the evidence means.
Accepted txid, accepted app receipt, local reject, replay row, or blocker. If it cannot be clicked or rebuilt, it stays lower confidence.
Under cap, required controller present, continuation preserved, timeout available, refund path open, or payout evidence matched.
Accepted TN12 spend plus matching artifact and plain wallet summary.
Local reject that shows the wrong move before anyone promotes the happy path.
Replay explains accepted records. It does not become custody just because the UI renders it.
How to read this
Some moves landed. Some were refused before broadcast.
That difference matters. This page keeps the user-facing result short and links the technical evidence one layer down.
A testnet transaction or app receipt landed on TN12 and has linked evidence.
A bad candidate failed in the local covenant or script checks before anyone should trust it.
The repo reads accepted records and reconstructs balances, receipts, or state changes.
What changes
The spend carries more of the rule.
A normal app can track a budget, payout, asset, or game step in a private database. These examples ask whether the spend itself can carry the rule, then let the app replay accepted records into readable state.
Money lives in UTXOs: spendable chunks with clear ownership.
Rules can affect how value moves, but state travels through outputs instead of one global contract account.
Fast ordering makes multi-transaction UTXO workflows easier to inspect as workflows and as settlement records.
Functional examples
Read each proof as a product job.
The artifacts matter because they show what moved, what was refused, and what a wallet or app could explain before the user signs.
Accepted spends and reset; local over-cap rejects.
Accepted route, return, timeout, and second role.
Accepted move; wrong-controller local rejects.
Wrong signer, wrong destination, missing relock, stale reset.
Accepted release spends and separate refund spends.
Accepted payout spend; trigger logic remains replay-derived.
Money can move under a visible limit, then the remaining money is locked back into the next budget state.
- Could be: parent wallet, team treasury, grant stream, merchant payout limit, game resource.
- Why it matters: the spending rule refuses the bad spend where the script enforces it. A dashboard can only report that refusal.
- Evidence: accepted TN12 budget spends, reset spend, post-reset spend, and local over-cap rejects.
One step goes to one role, returns with valid state, or recovers through timeout if it stalls.
- Could be: game turn, dispute step, service job, staged approval, claim/challenge flow.
- Why it matters: the accepted path becomes public evidence that a private server cannot silently rewrite.
- Evidence: accepted TN12 route, return, timeout, and second-role return. Not full game rules.
An asset moves only when the required controller input appears in the same transaction.
- Could be: ticket, access pass, game item, license, settlement right, app-owned asset.
- Why it matters: ownership follows transaction rules instead of a platform account row.
- Evidence: accepted TN12 controlled move plus local wrong-controller rejects.
Negative checks show the obvious bad moves: wrong signer, wrong destination, missing relock, over cap, and stale reset.
- Could be: vault safety screen, family wallet, escrow review, attack-path checklist.
- Why it matters: refusal evidence is stronger than a happy-path demo.
- Evidence: local script-engine rejects over an accepted budget path.
Coordination evidence shows fresh pledge outputs taking release paths and a separate fresh set taking refund paths.
- Could be: group buy, event deposit, public-goods grant, club project, cooperative funding.
- Why it matters: release/refund can be inspected from public evidence instead of only trusting a campaign database.
- Evidence: accepted TN12 release spends and accepted refund spends on separate fresh pledge sets.
Scheduler receipts tie an intent, bids, execution receipt, and a guarded payout spend into one reviewable story.
- Could be: subscription, payroll window, recurring payout, tournament turn, stale-action guard.
- Why it matters: users can replay whether the action was eligible before trusting the payout story.
- Evidence: accepted TN12 payout spend; trigger eligibility is still replay-derived.
Spotlight
Three clearest app patterns.
A task can move through a bounded role, come back, recover if it stalls, then continue through another role.
Accepted cumulative spends and a reset-window spend. The cap follows the next locked output.
An accepted asset move requires the right controller input in the same transaction.
Open strike evidence · Open controller-input details · Open wallet summary
Wallet review
What the wallet could show before signing.
A useful wallet should not ask users to sign an opaque blob. It should show the action, the checks, the reject cases, and the txid or artifact that backs the prompt.
Loading wallet summaries...
Experiment map
Technical evidence lives one click down.
Use these links for the full txids, covenant terms, status slugs, replay rows, and next blockers.