docs: sync TBV docs and screenshots to Confluence source

  Rewrite the Trustless Bitcoin Vault doc set to match the latest
  Confluence source of truth across all sections:

  - start-here: what-is-tbv, how-it-works, tbv-vs-alternatives,
    safety-and-trust-assumptions
  - testnet-info: setup, contract-addresses, protocol-parameters
  - use-for-lending: quickstart, create-a-vault, borrow-and-repay,
    withdraw-and-redeem, liquidation-risk
  - technical-details: protocol-architecture, protocol-actors,
    aave-v4-integration
  - reference: glossary, community-and-support

  Notable content changes: BABE described as a proof verifier (not
  fraud detection), vault bound to one application at peg-in, AVK /
  Application Vault Keeper terminology, added Application Vault Keeper
  and Security Council key tables to contract-addresses, trimmed
  glossary to the canonical term set.

  Sync use-for-lending screenshots: add 2026-06-01 borrow/repay,
  create-a-vault, and quickstart captures plus withdraw captures;
  remove superseded borrow-and-repay JPGs.

Author: kkkk666

docs/trustless-bitcoin-vault/reference/community-and-support.mdx

@@ -11,31 +11,21 @@ Where to ask questions, follow announcements, file issues, or reach the team abo
 
 | Purpose | Where to go | Link |
 | --- | --- | --- |
-| General questions, chat with the community, get help while using the test app | Discord | [discord.gg/qwTzSmtP](https://discord.gg/qwTzSmtP) |
-| Announcements, release notes, status updates | Twitter / X | [@babylonlabs_io](https://x.com/babylonlabs_io) |
-| Real-time chat (alternative to Discord) | Telegram | [t.me/babyloncommunity](https://t.me/babyloncommunity) |
-| Source code, issue tracker, SDK | GitHub | [github.com/babylonlabs-io](https://github.com/babylonlabs-io) |
+| General questions, chat with the community, get help while using the demo app | Discord | [Join the Babylon🔶🔒 Discord Server!](https://discord.gg/qwTzSmtP) |
+| Announcements, release notes, status updates | Twitter / X | [Babylon (@babylonlabs_io) on X](https://x.com/babylonlabs_io) |
+| Real-time chat (alternative to Discord) | Telegram | [Official Babylon Public Community](https://t.me/babyloncommunity) |
+| Source code, issue tracker, SDK | GitHub | [Babylonlabs.io](https://github.com/babylonlabs-io) |
 | Partnership and press inquiries | Email | [bd@babylonlabs.io](mailto:bd@babylonlabs.io) |
-| Security Council recovery (lost self-claim inputs while VP is unresponsive) | Discord or partnership email | Reach the team via the channels above and request Security Council escalation |
 
 ## Where to ask what
 
-* **Stuck mid-flow on the test app:** Discord, in the Testnet support channel
-* **Found a bug in the UI or contracts (non-security):** open an issue on GitHub
-* **Question about how something works conceptually:** start with [What is TBV](../start-here/what-is-tbv.mdx), then ask in Discord
-* **Lost your WOTS keypair and claimer artifacts:** if the Vault Provider for that vault is also unresponsive, contact the team to initiate Security Council recovery. See [Withdraw & redeem](../use-for-lending/withdraw-and-redeem.mdx) for the self-claim path's input requirements and [Safety & trust assumptions](../start-here/safety-and-trust-assumptions.mdx) for the recovery flow
+* **Stuck mid-flow on the demo app:** Discord, in the Testnet support channel
+* **Found a bug in the UI or contracts:** open an issue on GitHub and contact us
+* **Question about how something works conceptually:** check [TBV Testnet FAQ](../use-for-lending/faq.mdx) first, then Discord
 * **Press, partnerships, or business inquiries:** email the address above
 
-## Response time expectations
-
-Team response times vary by time zone; expect within 24 hours on business days for non-urgent questions in Discord. For time-sensitive issues during a Testnet flow (e.g. peg-in stuck for many hours), use the dedicated Testnet support channel on Discord and the team can usually respond faster.
-
 ## Safety reminders
 
 The TBV team will **not** ask for a private key, seed phrase, or signed transaction in any community channel. Anyone making such a request is impersonating the team.
 
 The team will also not initiate direct messages requesting funds, transactions, or credentials. If you receive a suspicious DM, report it in the public channel.
-
-## Related
-
-* [Setup](../testnet-info/setup.mdx) — getting started prerequisites

docs/trustless-bitcoin-vault/reference/glossary.mdx

@@ -7,60 +7,60 @@ sidebar_position: 2
 
 ## The big picture
 
-A **Trustless Bitcoin Vault (TBV)** spans two networks. BTC stays on the Bitcoin network for the vault's entire lifetime. Ethereum runs a coordination contract that tracks each vault's state and integrates with DeFi applications such as Aave v4. The trust assumption is cryptographic evidence — no bridge, no off-chain oracle, no wrapping custodian.
+A **Trustless Bitcoin Vault (TBV)** spans two networks. BTC stays on the Bitcoin Network for the vault's entire lifetime. On Ethereum, a protocol contract tracks each vault's state and registers DeFi applications such as Aave v4. The trust assumption is cryptographic evidence: no bridge, no off-chain oracle, no wrapping custodian.
 
-Two cryptographic primitives connect the chains:
+Cross-chain state transitions are enforced through cryptography, not by a trusted intermediary:
 
-* A hash time-locked contract (HTLC) on Bitcoin pairs with a hashlock commitment on Ethereum. Revealing the preimage on Ethereum unlocks the matching Bitcoin transaction. This is how a vault activates.
-* A zero-knowledge proof of an Ethereum state change (loan repaid, position liquidated, depositor exit) is generated off-chain, then verified directly on Bitcoin via the BABE construction (a cut-and-choose protocol in the BitVM3 family that fits inside Bitcoin's existing script primitives). This is how a vault is redeemed.
+* **Collateral activation** atomically binds the Ethereum-side activation of Bitcoin collateral to the lockup of BTC in the co-signed Taproot script that holds the vault's BTC. A hash time-locked output on Bitcoin pairs with a hashlock commitment on Ethereum; revealing the preimage on Ethereum unlocks the matching Bitcoin transaction.
+* **Collateral redemption** uses a BABE-based challenge procedure that lets Bitcoin verify proofs of Ethereum redemption events using only existing Bitcoin script primitives. BABE is a proof verifier, not a fraud-detection mechanism; the protocol uses it to gate BTC release on cryptographic evidence of the matching Ethereum state.
 
-An on-Ethereum Bitcoin light client (implemented as smart contracts) verifies the state of Bitcoin-side vaults in the opposite direction, so Ethereum applications can act on Bitcoin events without trusting an off-chain oracle.
+Each chain independently verifies the cryptographic evidence it receives. The Bitcoin side holds the BTC in a Taproot script with multiple spending paths agreed at vault creation.
 
-Each chain independently verifies the cryptographic evidence it receives. The Bitcoin side holds the BTC in a Taproot script with multiple spending paths agreed at vault creation. The Ethereum side holds an internal accounting token, **vaultBTC**, that represents the vault for DeFi purposes and is minted automatically when the vault is activated as collateral.
+![TBV peg-in flow: lock BTC, prepare vault, and activate vault through Ethereum coordination](/img/trustless-bitcoin-vault/confluence/start-here/how-it-works/TBV5-networks.png)
 
 ## Peg-in: vault creation
 
 Vault creation locks BTC into a Bitcoin transaction and registers the vault on Ethereum.
 
-The depositor submits a peg-in request to the Ethereum coordination contract. The request includes a hashlock — the SHA-256 hash of a secret only the depositor knows. The depositor then broadcasts the Pre-PegIn Bitcoin transaction that locks BTC into a Taproot address committed to that hashlock.
+The depositor submits a peg-in request to the BTC Vault Manager contract on Ethereum. The request includes a hashlock (the SHA-256 hash of a secret only the depositor knows) and the chosen Vault Provider. The depositor then broadcasts the Pre-PegIn Bitcoin transaction that locks BTC into a Taproot address committed to that hashlock.
 
-While the Pre-PegIn transaction accumulates Bitcoin confirmations, the depositor and the Vault Keepers (off-chain participants that co-sign the vault's transaction graph; none of them have custody of your BTC) complete an off-chain setup. They construct the vault's transaction graph — the complete set of pre-signed transactions covering every legitimate spend path (repayment, liquidation, refund, challenge). Each participant signs their part.
+While the Pre-PegIn transaction accumulates Bitcoin confirmations, the depositor and the Application Vault Keepers (off-chain participants that co-sign the vault's transaction graph; none of them have custody of the depositor's BTC) complete an off-chain setup. They construct the vault's transaction graph: the complete set of pre-signed transactions covering every legitimate spend path (each redemption path, the fraud-challenge response, and the Pre-PegIn refund). Each participant signs their part.
 
-The vault enters its Active state when the depositor reveals the hashlock secret on Ethereum. The protocol uses the secret to construct the final witness for the Bitcoin transaction that moves BTC into its vault location.
+First, all required participants collect and submit their signatures. Once the signatures are in, the depositor reveals the hashlock secret on Ethereum, and the vault becomes active. The protocol uses the secret to construct the final witness for the Bitcoin transaction that locks the BTC inside the BTC Vault.
 
-Two safety properties are built into the peg-in flow:
+Two safety properties are built into the deposit (peg-in) flow:
 
 * **Pre-signed transactions.** Every spend path is signed at vault creation by all required participants. After creation, no party can fabricate a new spend. Each path the BTC could ever take is committed up front.
-* **Refund timelock.** If the peg-in stalls (the depositor never reveals the secret, or participants fail to complete setup), the depositor recovers the BTC unilaterally via a Bitcoin-side refund timelock on the Pre-PegIn output.
+* **Refund hash timelock.** If the peg-in stalls (the depositor never reveals the secret, or participants fail to complete setup), the depositor recovers the BTC unilaterally via a Bitcoin-side hash timelock on the Pre-PegIn output.
 
-![TBV peg-in flow: lock BTC, prepare vault, and activate vault through Ethereum coordination](/img/trustless-bitcoin-vault/confluence/start-here/how-it-works/TBV5-networks.png)
+## Activating a vault as collateral in Aave v4
 
-## Using TBV as collateral
+An active vault is automatically supplied as collateral on the application chosen at peg-in. On activation, the BTC Vault Manager notifies the Aave v4 Adapter. The adapter mints an internal accounting token (vaultBTC) for the vault's BTC amount and supplies it to the **Babylon Core Spoke**, the dedicated Aave v4 market that accepts vaultBTC as collateral. The vault is appended to the depositor's lending position; subsequent activations add to the same position.
 
-An active vault is automatically supplied as collateral. On activation, the protocol mints vaultBTC for the vault's BTC amount and supplies it to the **Babylon Core Spoke** — a dedicated Aave v4 market for vaultBTC collateral. The vault is appended to the depositor's lending position; subsequent activations add to the same position.
+A BTC vault is created for one specific application at peg-in and cannot be moved between applications later. The protocol is designed to support multiple applications, but each requires its own adapter and its own vaults; integration is not "out of the box".
 
-The depositor can then borrow stablecoins (USDC, USDT) or WBTC against that collateral.
+From this point, the depositor can borrow stablecoins (USDC, USDT) or WBTC against the collateral.
 
-The vaultBTC token never leaves the protocol contracts. It cannot be transferred to arbitrary addresses or traded on secondary markets. Its only purpose is internal accounting of vault-backed collateral.
+The vaultBTC token is an internal accounting construct of the Aave Adapter. It is not transferable to arbitrary addresses, has no secondary market, and never appears outside the Aave adapter contracts. Its purpose is to translate the indivisible BTC vault into something Aave can understand as collateral.
 
-Additional vaults can be created at any time; each is supplied automatically on activation. Vaults can be withdrawn individually as long as the position remains healthy (its health factor — the ratio of risk-adjusted collateral to debt — stays above 1.0). With multiple vaults in a position, the protocol can do partial-position liquidation: if liquidation is triggered, it seizes only the subset of vaults required to restore the health factor, leaving the rest in the position. With a single-vault position, liquidation seizes the whole vault.
+Additional vaults can be created at any time, each can be withdrawn individually as long as the position remains healthy (its health factor, the ratio of risk-adjusted collateral to debt, stays above 1.0).
 
-In multi-vault positions the order matters. The protocol walks the vault list in order during liquidation and seizes the minimum prefix needed. Vaults at the front are taken first. This is why the app recommends splitting BTC between a sacrificial vault (sized to cover the protocol's expected seizure, placed first) and a protected vault (whatever remains, placed second). At current Testnet parameters the sacrificial vault is the larger of the two; see [Liquidation risk](../use-for-lending/liquidation-risk.mdx) for the sizing logic.
+## What "liquidation" means for a vault
 
-When a vault is withdrawn from a position — either by the depositor exiting, or by liquidation — the corresponding vaultBTC is burned. The vault then enters the redemption flow on Bitcoin.
+A BTC vault is a single Bitcoin UTXO. It is indivisible: the protocol can only seize a whole vault, never a fraction. When a position is liquidated, the protocol seizes one or more whole vaults; what stays is the remainder of the position.
 
-![TBV liquidation model: ordered vaults allow liquidation to seize only what is needed while leaving protected vaults untouched](/img/trustless-bitcoin-vault/confluence/start-here/how-it-works/TBV3-LIQUIDATION.png)
+With a single-vault position, any liquidation seizes the whole collateral backing the position (full-position liquidation). With multiple vaults, the protocol walks the depositor's ordered vault list and seizes the minimum prefix needed to restore the health factor (partial-position liquidation). The vaults at the front of the list are taken first.
 
-## Peg-out: vault redemption
+## Vault redemption
 
-When a depositor is done with a vault, or when liquidation triggers, the vault enters the redemption flow on Bitcoin. There are two main paths and one safety fallback.
+When a depositor is done with a vault, or when liquidation triggers, the vault enters the redemption flow on Bitcoin. The Bitcoin side knows only "redeem": the application layer (Aave v4) translates the depositor's action (withdrawal after repayment, or liquidation triggered by another address) into the redeem call. There are two main paths and one safety fallback.
 
-**Path 1: repay and exit.** After repaying the loan, the depositor withdraws the vault from the lending position. This burns the corresponding vaultBTC and triggers vault redemption on the Bitcoin side. The Vault Provider generates a zero-knowledge proof that the burn event happened on Ethereum, submits a claim transaction on Bitcoin, and after the challenge period ends, the BTC is released to the depositor's Bitcoin address (minus the Vault Provider's commission).
+**Path 1: withdrawal after repayment.** After repaying the loan, the depositor withdraws the vault from the lending position. This burns the corresponding vaultBTC and triggers vault redemption on the Bitcoin side. The protocol contracts emit a redemption event for the depositor to withdraw the vault on Ethereum, submit a claim transaction on Bitcoin, and after the challenge period ends, the BTC is released to the depositor's Bitcoin address (minus the Vault Provider's commission).
 
-**Path 2: liquidation.** If the position's health factor drops below 1.0, anyone can call the liquidation function on Ethereum. The liquidator repays the debt and the protocol seizes the necessary vaults. The seized vaults then enter the same redemption flow, but with the claimer being an arbitrageur — either one with a Bitcoin redeem key (redeeming directly), or one who acquires the vault from BTCVaultSwap after a permissionless liquidation. The depositor receives a fairness payment in WBTC for any seized value exceeding what was owed to the liquidator.
+**Path 2: liquidation.** If the position's health factor drops below 1.0, anyone can call the liquidation function on Ethereum. The liquidator repays part of the debt and the protocol seizes the necessary vaults. The seized vaults then enter the same redemption flow, with the claimer being a registered Application Vault Keeper (an arbitrageur in the Aave integration) who may or may not also be the liquidator that triggered the seizure. The over-seized value is returned to the depositor either as additional debt repayment on their behalf (the common case during partial-position liquidation) or, on full-position liquidation when all debt is covered, paid in WBTC. See [Liquidation risk](../use-for-lending/liquidation-risk.mdx).
 
-**Trustless safety fallback: depositor self-claim.** If the Vault Provider becomes unresponsive (offline, refusing to process the redemption), the depositor can independently claim the BTC using a one-time signature key committed at vault creation, plus the depositor's locally-stored claimer artifacts. This path is **trustless**: it requires no cooperation from any Vault Keeper, Universal Challenger, or Vault Provider, and is always available as a fallback for normal exits.
+**Safety fallback: depositor self-claim.** If the Vault Provider becomes unresponsive (offline, refusing to process the redemption), the depositor can independently claim the BTC using a Winternitz One-Time Signature (WOTS) committed at vault creation, plus the depositor's locally-stored claimer artifacts. This path is **trustless**: it requires no cooperation from any Application Vault Keeper, Universal Challenger, or Vault Provider, and is always available as a fallback for normal exits.
 
-![TBV cross-network redemption flow](/img/trustless-bitcoin-vault/confluence/start-here/how-it-works/TBV4-networks.png)
+All three paths share the same finalization mechanism: a zero-knowledge proof verified on Bitcoin via the BABE construction, followed by a challenge period of approximately 3 days during which any Universal Challenger or Application Vault Keeper (or the depositor themselves) can dispute an invalid claim. If unchallenged or unsuccessfully challenged, the BTC is released.
 
-All three paths share the same finalization mechanism: a zero-knowledge proof verified on Bitcoin via the BABE construction, followed by a ~3 day challenge period during which any Universal Challenger or Vault Keeper — or the depositor themselves — can dispute an invalid claim. If unchallenged, the BTC is released.
+![TBV cross-network redemption flow](/img/trustless-bitcoin-vault/confluence/start-here/how-it-works/TBV4-networks.png)