> For the complete documentation index, see [llms.txt](https://docs.adcpcapital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adcpcapital.com/products/btc-secured-credit.md).

# BTC-Secured Credit (Series 002)

**Status: Working proof / controlled pilot.** This is the one product currently demonstrated end-to-end, live on Base Sepolia.

## Concept

A BTC holder wants liquidity without necessarily selling their BTC. The financial partner owns the client relationship and the product. A capital provider supplies eligible USDC. ADCP enforces the capital, collateral, credit, reserve, and accounting rules underneath. Regulated custodian / bank / VASP arrangements sit alongside this flow where applicable, and remain the partner's relationships, not ADCP's.

## Who does what

| Party                 | Role                                                                                                                                        |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| BTC holder / borrower | Provides eligible BTC collateral; accesses liquidity without necessarily selling BTC.                                                       |
| Capital provider      | Supplies USDC lending capital; receives the entitlement defined by the product from actual realized credit activity — no guaranteed return. |
| Financial partner     | Owns the client relationship, product, and regulated role as structured; keeps the client, adds a product capability.                       |
| ADCP                  | Enforces capital, collateral, credit, reserve, and accounting rules.                                                                        |

The "financial partner" role above is a business-model relationship, not an on-chain role — the protocol does not need to represent it as a smart-contract permission.

## Mechanics (implemented)

* A borrower posts BTC (represented on-chain as a collateral asset in the current pilot's configuration) and originates a loan denominated in USDC, subject to a maximum loan-to-value (LTV) and minimum loan size.
* The position accrues interest under an immutable-per-deployment rate configuration.
* If the position's health falls to or below the liquidation threshold, it becomes eligible for liquidation under a deterministic, immutable-per-deployment liquidation configuration (bonus, protocol fee, close factor).
* Origination and liquidation both read live price data through an oracle layer with an explicit health classification (`VALID`, `STALE`, `UNAVAILABLE`, `DEVIATING`) — see [Risk and Solvency](/protocol/risk-and-solvency.md).
* Full and partial repayment, and collateral withdrawal subject to a post-withdrawal safety check, are both implemented.

See [Credit and Collateral](/protocol/credit-and-collateral.md) for the full mechanics and [Contract Interfaces](/developers/contract-interfaces.md) for the exact contract surface.

## What is not implied

No return, yield, liquidity, collateral value, or borrower outcome is guaranteed. Every parameter used in the current controlled pilot (LTV, liquidation threshold, interest rate range, reserve/utilization ceilings) is an initial pilot calibration, not a claimed-optimal or final production value.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.adcpcapital.com/products/btc-secured-credit.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.