Verify your position
A useful position record connects what you authorized with what happened on both chains. A balance or transaction ID alone does not show that whole relationship.
Use the deployment’s public chain records and the transaction package supplied by your signing flow.
Start with the current outpoint
A Bitcoin outpoint is a transaction ID and output index: txid:vout.
Check its amount, locking script, confirmation depth and whether it remains unspent. After a withdrawal or liquidation, follow the actual transaction to the new remainder. The original vault address or outpoint is no longer enough.
Match the authorization
Check the position binding: customer Bitcoin key, Ethereum owner, session and child index. Using the construction parameters, customer key and ordered cheque/event commitments, reconstruct the vault script and compare it with the output. Verify each supplied leaf and control block against that same output.
The transaction package should let you inspect:
- The signed input and every payout, remainder, surplus, fee and anchor.
- The intended oracle family, epoch, outcome, position-bound points and event-keyed cheque leaf.
- Each child transaction’s exact parent outpoint and relative delay.
- Replacement coverage for each reachable remainder.
- The customer-authorized recovery and veto transactions.
A signed transaction establishes customer authorization of its committed contents. Guardians separately verify the resulting settlement and enforce the protected return path when it is invalid.
Match Ethereum’s record
Verify the network and contract set, then compare the recorded collateral outpoint and amount with Bitcoin. Check the registered script for the depositor key, construction version and position identifier. Read the customer’s debt and any pending claims or settlement status.
After a partial liquidation, both chains should identify the same remainder and Ethereum should reflect reduced debt. After terminal liquidation, verify the collateral removal, debt actually extinguished, any liability still outstanding and each customer refund. Signed BTC surplus and refunds in the borrowing asset are separate amounts.
Use finalized Ethereum state and the required Bitcoin confirmation depth. A stale indexer or an included-but-unfinalized transaction can give an incomplete picture.
What public chain data cannot prove alone
| Visible evidence | What it does not establish |
|---|---|
| A valid Taproot spend | That independent threshold signers produced it without reconstructing a secret. |
| A configured oracle threshold | That this CET actually required that threshold. |
| A confirmed deposit | That every required future transaction was signed and remains covered. |
| An Ethereum collateral balance | That its backing was credited through the intended proof and cap-enforcement route. |
Keep the signed package and public recovery records accessible alongside your signer. Never publish secret keys or secret nonces as verification evidence.
For a disagreement, record the two chain heights, transaction IDs and relevant public state. Those facts are more useful than a screenshot of a displayed balance.