TN12 testnet walkthrough

TN12 playground

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.

Landed

Role funding, two deposits, and one payout are accepted TN12 transactions.

Replayed

The repo turns those accepted rows into balances and blocked-action views.

Missing

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.

Request Move testnet funds

User A deposits 3 tKAS into the pool role on TN12.

Check Address and amount

The wallet should show the source, destination, network, amount, and fee before signing.

After submit Open the txid

The app state should update only after the accepted TN12 transaction is fetched and replayed.

Boundary Testnet walkthrough

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.

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.

Accepted txs4

Funding, two deposits, one payout.

Roles6

Fresh session public addresses.

Secrets published0

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

Verify before using app state.