Security

BTC Collateral Security

The Collateral Vault is secured using a 2-of-2 multi-signature scheme, ensuring that BTC collateral cannot be spent without the Borrower’s authorization. This mechanism enforces strict adherence to Bitcoin-native security principles and eliminates the possibility of unilateral control by any single party.

There are four valid spending paths for the collateral: (1) execution of one of three pre-signed CETs—covering price-based liquidation, loan default, or successful repayment; and (2) a hash time-locked refund mechanism that allows the Borrower to unilaterally reclaim collateral after a predefined timeout if the entire system becomes unresponsive.

At no point can the collateral be spent outside of these conditions. All control paths are strictly encoded within the DLC, ensuring the collateral remains non-custodial and fully governed by cryptographic enforcement.

Loan Asset Security

The Lending Contract, a smart contract deployed on the Side Chain, governs the management of loan assets according to predefined rules encoded within its framework. Liquidity Providers have the flexibility to enter or exit the liquidity pool at their discretion.

DCM Security

The DCM acts on behalf of the Lending Contract to co-sign required transactions. However, it’s important to emphasize that the DCM has no control over the Lending Contract itself or the Collateral Vault. Its function is strictly limited to managing bad debt on behalf of liquidity providers. Lenders’ funds remain non-custodial, securely locked within smart contracts at all times. The DCM only temporarily holds liquidated BTC collateral for the purpose of liquidation. To reduce risk and ensure timely liquidation, a bonus is offered to incentivize third-party liquidators to sell the collateral quickly.

To preserve the trust-minimized nature of the protocol, the DCM and the Event Signers must remain entirely independent entities.

Misconduct or failure by any DCM operator may result in strict penalties, including removal from the role. Furthermore, all DCM operators are required to undergo Know Your Customer (KYC) verification to ensure accountability and regulatory compliance.

Oracle Security

Side Protocol’s Oracle++ architecture separates the traditional role of a Bitcoin DLC oracle into two distinct components: Data Providers and Event Signers. This separation significantly increases the difficulty of fraud, as Oracle++ restricts Event Signers to attesting only to events generated from data provided by Data Providers.

Crucially, Event Signers cannot directly benefit from liquidation events, since only the borrower or the DCM can receive collateral. They also cannot fabricate arbitrary prices, as all valid attestations must be threshold-signed by a predefined quorum of signers. No individual Event Signer can unilaterally manipulate the protocol.

Unlike traditional DLC oracle designs—where a single party holds both the oracle’s private key and the λ of the adaptor point—Oracle++ uses DKG to derive these values. This ensures that no single operator knows the full private key and secret λ, eliminating the risk of key leakage or abuse.

In terms of liveness, Oracle++ ensures timely event announcements through randomized selection of active operator candidates. Signing resilience is provided via the FROST threshold signature scheme. Additionally, all oracle operators are KYC-verified to ensure accountability.