Trust Assumptions

While Side Protocol aims to minimize trust assumptions across all components of its infrastructure, certain trust dependencies are currently necessary—particularly for accessing liquidated collateral during on-chain liquidations. As the protocol evolves, there are clear plans to progressively reduce reliance on trusted entities and further decentralize these processes.

Major Trust Assumptions for Borrowers

Side Lending follows trust assumptions similar to other DLC-based systems, where the borrower’s BTC collateral is locked in a non-custodial 2-of-2 multisig vault, and the only two recipients in the transaction outputs are 1) the borrower and 2) their counterparty. In typical DLC use cases, the counterparty is a single signer—such as a lender in lending applications. In Side’s design, however, the counterparty is a Distributed Collateral Manager (DCM), a covenant committee implemented as a threshold signer set.

The only two spending conditions that allow the DCM to unilaterally withdraw collateral are pre-signed or pre-authorized by the borrower at the time of the loan request. Outside of these two conditions, there is no mechanism for any party to withdraw the borrower’s collateral.

For the DCM to execute a unilateral withdrawal, it must rely on signed attestations from an oracle that confirm both the BTC price and a valid timestamp. Since the oracle is not a recipient in the transaction outputs, it cannot directly control or move funds. This setup means that borrowers must trust that the oracle and the DCM will not collude to fabricate liquidation conditions and seize the collateral.

Side mitigates this risk through a protocol-level architecture in which the oracle is enshrined and operated by the chain’s validator set, meaning it can only be corrupted through majority control of network governance. The DCM, by contrast, is a completely separate entity composed of whitelisted and KYC-verified members operating under a threshold signature scheme.

This strong separation of roles and governance domains significantly reduces the risk of collusion and strengthens the system’s non-custodial security guarantees.

Major Trust Assumptions for Lenders

Oracle security

There are two conditions under which borrowers can retrieve their BTC collateral: (1) by repaying the loan, or (2) through the expiration of a failsafe timeout. The failsafe serves as a backstop, allowing borrowers to reclaim their collateral if the DCM or Side Chain fails to act. Lenders must trust that borrowers cannot manipulate the oracle into withholding repayment attestations and wait for the timeout to expire in order to withdraw their BTC without repaying. However, since the oracle is enshrined at the protocol level and operated by the chain’s validator set, compromising it would require gaining majority control of network voting power.

DCM security

Lenders must trust that once the DCM claims collateral from a borrower’s vault, it will act according to protocol rules—specifically by selling the seized BTC to external liquidators who, in turn, repay the equivalent debt into the liquidity pool. This process ensures that lenders can redeem their sTokens for the correct amount of underlying assets. If the DCM fails to execute this process or mismanages the collateral, it could result in a shortfall within the pool.

To mitigate this risk, the DCM is structured as a whitelisted, KYC-verified threshold signing committee, independent from the oracle and validator governance systems. In the event that the DCM fails to sign required liquidation transactions, it can be removed and replaced with a new set of signers, ensuring operational accountability and protecting lender funds.