Add Phase-2 TBV testnet documentation#443
Conversation
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
🔐 Commit Signature Verification✅ All 2 commit(s) passed verification
Summary
Required key type: Last verified: 2026-06-03 01:49 UTC |
Greptile SummaryThis PR publishes Phase-2 TBV testnet documentation. The main changes are:
Confidence Score: 4/5This is close, but the self-challenge docs should be fixed before merging.
Important Files Changed
Reviews (1): Last reviewed commit: "docs(tbv): add phase 2 testnet documenta..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| The protocol is designed to progressively decentralize participation. Two protocol surfaces have permissionless elements: | ||
|
|
||
| * **Fraud monitoring.** Anyone can monitor for fraudulent claims by running a watcher and checking Ethereum-side events. Broadcasting an on-chain `ChallengeAssert` requires being a registered Universal Challenger in the current `ProtocolParams` set; the registry is governed at the protocol level. The Testnet roadmap includes progressive opening of the challenger set so additional operators can earn challenger rewards by successfully disputing invalid claims. |
There was a problem hiding this comment.
This line says broadcasting an on-chain ChallengeAssert requires being a registered Universal Challenger, but this new page also says the depositor can broadcast ChallengeAssert themselves when no Universal Challenger acts. The safety page repeats that self-challenge as a core trust assumption. Readers now get two incompatible recovery models: either depositors can block a fraudulent claim themselves, or they cannot unless they are registered challengers. Please make this permissioning consistent so operators and depositors know which recovery path is actually available.
|
|
||
| With the proof generated, the claimer follows the Bitcoin-side flow: | ||
|
|
||
| * **Claim transaction.** Spends from the vault's Taproot output via the appropriate leaf (repayment, liquidation, or refund). |
There was a problem hiding this comment.
This peg-out section lists refund as one of the Claim transaction leaves for spending the vault output. The same page describes refund as the Pre-PegIn HTLC expiry path, while peg-out is triggered by withdrawal, liquidation, or direct redemption after a vault is Active/Redeemed. As written, implementers can read this as saying an active vault redemption uses the refund leaf, which mixes two different Bitcoin outputs and lifecycle states.
| * **Claim transaction.** Spends from the vault's Taproot output via the appropriate leaf (repayment, liquidation, or refund). | |
| * **Claim transaction.** Spends from the vault's Taproot output via the appropriate leaf (repayment or liquidation). |
| "label": "Use TBV Testnet For Borrowing", | ||
| "position": 4, | ||
| "collapsible": true, | ||
| "collapsed": true, | ||
| "link": { | ||
| "type": "generated-index", | ||
| "description": "Depositor critical path for the Aave v4 integration on TBV: step-by-step walkthroughs from the first peg-in to redeeming BTC." | ||
| "description": "Borrower critical path for the Aave v4 integration on TBV: step-by-step walkthroughs from the first peg-in to redeeming BTC." |
There was a problem hiding this comment.
This category label was renamed to “Borrowing”, but the TBV sidebar is manually defined in sidebars-default.js and still hardcodes “Use TBV Testnet For Lending”. Because this _category_.json is not what renders that manual sidebar entry, the visible navigation keeps the old wording while the generated category metadata says something else.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| { | ||
| "label": "Technical Details", | ||
| "position": 5, | ||
| "collapsible": true, | ||
| "collapsed": true, | ||
| "link": { | ||
| "type": "generated-index", | ||
| "description": "Optional deeper reading: protocol architecture, actors, and the Aave v4 application layer. Not required to use the product on Testnet." | ||
| } | ||
| } |
There was a problem hiding this comment.
This new technical-details category is only defined through _category_.json, but the Trustless Bitcoin Vault docs use a manually enumerated sidebar in sidebars-default.js. Since that sidebar was not updated with the Technical Details category or the new Safety page, these newly published Phase-2 pages are reachable by direct URL but are not discoverable from the TBV navigation.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
Summary
Confluence alignment
Validation
ALGOLIA_APP_ID=local ALGOLIA_API_KEY_READONLY=local npm run buildrelease/v3.xstaking-script fetch 404, Docusaurus markdown config deprecation, stale Browserslist data, and existing top-level redirect warnings for/stakers,/developers,/operators.