Role funding, two deposits, and one payout are accepted TN12 transactions.
Real TN12 transactions. Open the evidence.
Accepted testnet flow, replayed app state.
Fresh role wallets got funded, two users deposited to a pool role, the pool paid one user back, and replay turned accepted txids into balances and blocked actions. This is a testnet walkthrough, not a production app.
How to read this walkthrough
Accepted txids first, replay second.
Click the testnet transactions before trusting the app state. The replay view explains balances and blocked actions from accepted records; it does not make this a production custody system.
The repo turns those accepted rows into balances and blocked-action views.
Public-user wallet signing, production replay, audit, and mainnet activation remain separate work.
Wallet view
What the user should see before signing.
The playground is useful when it turns raw transaction work into approval checks: action, amount, destination, evidence after submit, and the reason a bad path should stop.
User A deposits 3 tKAS into the pool role on TN12.
The wallet should show the source, destination, network, amount, and fee before signing.
The app state should update only after the accepted TN12 transaction is fetched and replayed.
No mainnet funds, no audited custody, and no claim that replay-derived state controls money.
Start here
Choose a testnet route.
Review the accepted run, repeat it with faucet tKAS, or use the same pattern for a TN12 app-state flow.
Pick a path
Skip around.
Funding, two deposits, payout, replay.
Inspect Open addressesRole wallets and explorer links.
Run Make fresh rolesGenerate wallets, fund, submit.
Build Open lab toolsVault, assurance, outpoint, and app-receipt workbench.
Explore Open experiment mapBudgets, controlled assets, step workflows, refunds, scheduled payouts, and blocked withdrawals.
Review Check replayed stateBalances and blocked actions.
Live session tape
What happened on TN12.
Choose your depth
Beginner to technical view in one page.
Pool-style testnet flow.
Users deposited into a pool role, the pool paid one user back, and replay turned the accepted txids into balances. This is not an AMM, lending market, liquidation engine, oracle system, or production custody path.
Plan summary
What this run contains.
Funding, two deposits, one payout.
Fresh session public addresses.
Only public addresses and txids are committed.
Current session
Explorer-checkable tx flow.
Faucet flow
Try the same pattern.
Show local commands
Prereqs: run npm ci, use throwaway TN12 wallets only, and keep source funding explicit. playground:wallets creates fresh role addresses. playground:funding-draft funds those roles from TN12_WALLET plus FUNDING_OUTPOINT, defaulting to .local/tn12-wallet.json and fixtures/FundedWalletOutpoint.json. Treat --submit as a real testnet broadcast.
npm run playground:wallets npm run playground:funding-draft node scripts/submit-signed-draft.mjs .local/playground/funding-draft.json --submit
If you just want to observe, skip the commands and click the txids above. If you want to run it, generate fresh roles, fund them with faucet tKAS or your own TN12 wallet, then replay the artifacts.
Your wallet
Play without sharing keys.
The wallet-blocked path is simple: the repo prepares a request, your wallet signs, the repo validates the returned bytes, and app state moves only after accepted replay.
Role wallets and available checks Open when you need addresses, funding targets, and session actions.
Role wallets
Suggested testnet roles and funding.
Available checks
What this session can verify.
Replay output and verification rules Open when you want replayed balances, blocked rows, and promotion rules.
Replay state
What current accepted rows reduce to.
Verification rules