Collateralization is a foundation of on-chain finance. It secures loans, credit cards, and option positions. It also serves as the reserve that underpins the claims-paying capacity of insurance and other risk coverage products.
Bitcoin is a pristine collateral asset for on-chain finance. Like gold, it is a (digital) store of value, widely accepted, with deep liquidity and relatively low volatility compared to other digital assets. There is also a strong social consensus around “hodling”. Therefore, collaterizing Bitcoin to acquire the liquidity of other digital assets is a potential strategy for both Bitcoin holders and applications that seek capital efficiency.
However, deploying Bitcoin as collateral may incur additional counterparty risks compared to other digital assets. The Bitcoin chain’s minimalistic design and lack of programmability means it’s difficult to host on-Bitcoin-chain applications and challenging to deploy Bitcoin on other chains. Thus, Bitcoin collateral solutions may rely on certain off-chain systems (such as tri-party agreements) or centralized operations (such as exchanges and multi-sig bridges), which could introduce extra counterparty risks.
In this article, we share SCRIPT, the risk assessment framework that the Babylon team has been using internally for our native Bitcoin collateral protocol design. Bitcoin holders and applications can use SCRIPT to systematically assess the counterparty risks of any Bitcoin collateral solutions, including Babylon’s.
SCRIPT consists of six risk categories:
- Sovereignty: Sovereign title retention by the Bitcoin holder
- Clarity: Clear collateral disposition rules that are pre-committed and objective
- Reuse prohibited: Reuse (such as rehypothecation) of the collateral without consent is prohibited
- Isolation: Isolated collateral for each Bitcoin holder
- Permissionless: No third party can censor the system
- Transparency: Transparent and easily auditable collateral positions.
A full breakdown and how to de-risk is provided in the table below:
| Risk Category |
Description |
How to Derisk |
Who Should Care |
| Sovereignty |
Sovereign title retention by the Bitcoin holder
The Bitcoin holder should ideally retain meaningful control over the native Bitcoin collateral until a pre-defined liquidation condition is triggered. Otherwise, the Bitcoin holder may lose title to the Bitcoin at the point of entry, creating accounting, tax, and compliance challenges.
(Not tax or legal advice)
|
Use solutions in which the Bitcoin holder does not have to surrender control of their Bitcoin.
Avoid situations in which the Bitcoin is fully under the control of a third party.
|
Bitcoin holders |
| Clarity |
Clear collateral disposition rules that are pre-committed and objective
Collateral disposition, including redemption, liquidation, seizure, etc., must follow clear, pre-committed, and objective rules.
There should not be any hidden rules, and no party should be able to alter, override, or ignore those rules without the authorization of both the Bitcoin holder and the application.
|
Use solutions in which the disposition rules are fully published, transparent, and programmed, with a strict upgrade approval process.
|
Bitcoin holders and applications |
| Reuse Prohibited |
Reuse, such as rehypothecation, of the collateral prohibited
Native Bitcoin collateral should not be transferred, rehypothecated, or exposed to competing claims without clear disclosure and informed consent.
Otherwise, the risk of Bitcoin loss for the Bitcoin holder or bad debts for the application is significantly increased.
|
Use solutions in which any collateral reuse, prior encumbrance, or third-party claim is either prohibited or clearly disclosed and expressly consented to.
|
Bitcoin holders and applications |
| Isolation |
Isolated collateral for each Bitcoin holder
If users’ Bitcoin collateral is pooled, attribution to a specific position can weaken. That can create compliance and screening issues if some Bitcoin in the pool is later identified as tainted or high-risk.
|
Use solutions in which collateral remains isolated or clearly attributable to each user position.
|
Bitcoin holders |
| Permissionless |
No third party can censor the system
The life cycle of the native Bitcoin collateral should be permissionless. No one should have the ability to:
• censor the deployment of the collateral
• censor the usage of the collateral in the application
• censor the disposition of the collateral
Otherwise, the risk of Bitcoin loss for the Bitcoin holder or bad debts for the application is significantly increased.
|
Use solutions in which the end-to-end system is not centralized and is enforced by code.
|
Bitcoin holders and applications |
| Transparency |
Transparent and easily auditable collateral positions
Each collateral position in the application should ideally have transparent and easily auditable native Bitcoin collateral on the Bitcoin chain.
If not, the application may be exposed to under-collateralization, de-peg, and bad debt risk.
|
Use solutions in which each collateral position is attributable, easily identifiable, and auditable to native BTC collateral.
|
Applications |
.png)
