Accepted TN12 transactions show role funding, user deposits, and a pool payout.
Accepted TN12 activity. Replayed state.
Funds moved. Receipts landed. The repo replays them.
Start with the concrete run: six role wallets funded on TN12, two user-to-pool deposits accepted, one pool-to-user payout accepted, then the repo turns txids into balances and blocked actions.
Read this first
The same run has different kinds of evidence.
Accepted payloads record intent or status. A receipt alone is not custody settlement.
The repo reads accepted rows and calculates balances and blocked actions.
User-wallet signing, production replay, audit, and mainnet activation need separate evidence.
Accepted txids and derived results
Start from the accepted txid.
Each row starts with a TN12 transaction, then shows what the repo derives from it and what still needs separate evidence.
Six public testnet roles received tKAS in one accepted transaction.
Use: repeatable session setup. Boundary: testnet funds only.User A and User B moved tKAS into the pool role.
Use: visible contribution trail. Boundary: not AMM or lending custody.The pool role paid User B and the txid can be opened directly.
Use: settlement-style row. Boundary: no production signer yet.The repo turns accepted rows into readable state.
Use: inspection path. Boundary: replay explains state; it does not control funds.Quick check
Start with what happened.
This page shows the run in order: accepted money movement first, app receipts second, replayed state third, open gaps last. Open the playground for the run. Use Lab Tools for commands, artifacts, and unfinished builder work.
Watch
Accepted TN12 flow
Funding, two deposits, payout, replay.
Receipts Accepted app receiptsPayload rows accepted on TN12.
Evidence What has proofProofs, transfers, replay, and next pieces.
Future Future ideasOptional adapter ideas stay behind a drawer because they are not proof from the accepted run.
Current evidence summary
What the latest run contains.
Role funding, two deposits, and one payout.
Operator, pool, User A, User B, executor, observer.
Accepted txids reduce into balances and blocked actions.
Explain it by level
Same evidence, different vocabulary.
What is happening
Transaction -> receipt -> replay.
The important state changes have public txids. The app replays accepted TN12 records and marks which parts are replay logic, with no custody or market execution.
Six session wallets received tKAS in one accepted TN12 tx.
User A and User B each moved tKAS into the pool role.
The pool sent tKAS back to User B.
The ledger converts accepted txids into review state.
Accepted records
What is backed by accepted records.
Rows summarize accepted evidence, replay state, and the remaining pieces. Open explorer links and artifacts when you need the mechanical proof.
Recent accepted receipts
Latest app-state rows.
Show recent accepted receipt rows
TN12 playground
Accepted testnet session flow.
Open the playground for the role addresses, accepted txids, replay output, and blocked-action view.
Future ideas
Adapter ideas are sketches.
These rows are possible integration shapes. The accepted TN12 run does not prove them yet.