Security

Side Finance operates as a non-custodial solution, meaning no third party holds the native BTC on the Bitcoin blockchain throughout the loan's duration. The main trust assumption arises during two key processes: the liquidation of collateral through auctions and the repayment settlement.

BTC Collateral Security

The Collateral Vault is secured using a 2-of-2 multi-sig combined with a Hash Time-Locked Contract (HTLC), ensuring that BTC collateral cannot be moved without the Borrower’s authorization. There are four methods to spend UTXOs associated with this address, all of which adhere to Bitcoin-native security principles:

1. using CETs of a Discreet Log Contract (DLC) in the event of collateral value depreciation, relying on Schnorr adapter signatures

2. through a Borrower-generated repayment_secret and a counter-signed adapted signature from the DCA that accepts loan repayment

3. a hash timelock that activates in the case of loan default (when repayment is not made before the Maturity Time), allowing the DCA to spend the collateral

4. a final hash timelock that allows the Borrower to reclaim all collateral in the event that Side Finance stops responding

In no case does any single entity have discretion over a Borrower’s BTC collateral outside the terms specified in the “contract” encoded within the DLC.

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.

Oracle Security

In a Bitcoin DLC-based DeFi system like Side Finance, oracles must cryptographically sign periodic price attestations, enabling the liquidation of Bitcoin when necessary. Oracle operations need to be decentralized, run by operators who have an economic stake in the system that can be slashed if they act maliciously.

21 well-known Side Chain validators, chosen through on-chain governance by stakers, also serve as Oracle Operators. These validators are selected due to their vested interest in the system's success and their role in securing value across multiple chains. Should any validator provide incorrect price outputs, a cryptographically signed proof of misbehavior is generated. This proof automatically affects their stake holdings on Side and damages their reputation on other chains they secure.

It’s important to note that Oracle Operators cannot benefit directly from any price liquidation events they sign, that they cannot make up arbitrary prices, and that a threshold set of operators must agree in order for a price to be signed.

Each Oracle Operator independently monitors Bitcoin prices from multiple cryptographically secure upstream sources. The public keys of these approved upstream price sources, selected by on-chain governance, are stored within the Oracle smart contract on the Side Chain.

The Oracle Operators collectively produce a stream of DLC signatures for potential future price events. Later, they sign an attestation of the real BTCUSD price for each time period as it occurs. These DLC signature streams and attestations are then used by the DCA to liquidate loans that fall below the Liquidation Price.

Price attestations proceed as follows:

1. An Oracle operator proposes a price to the Oracle smart contract for a recently passed time period and signs the proposal. The Oracle smart contract verifies the validity of the upstream source’s signature. If the signature is invalid, the proposing operator’s stake is automatically slashed, and the operator is flagged for investigation.

2. Other Oracle operators independently monitor BTC prices by retrieving data from approved sources. As prices may differ slightly at any given time, if the proposed price falls within a specified tolerance (e.g., 0.5%) of an operator’s verified price, the operator signs the proposed price. If the proposed price falls outside this tolerance, the operator does not sign and instead re-proposes a new price, which is again checked for validity.

3. This process repeats until all Oracle operators reach a consensus on the price. If consensus cannot be achieved, the system halts price attestations until the issue is resolved through human intervention. A small minority of honest operators is enough to prevent the Oracle from signing an incorrect price.

Oracle Operator Slashing

Oracle operators should monitor the complete set of approved upstream oracles and base their price proposals on the median price. If a proposed price deviates significantly from the median price attested by upstream sources, anyone can initiate a slashing challenge.

Since all upstream prices are cryptographically signed and the public keys of approved upstream oracles are stored in the Oracle smart contract on Side Chain, a challenger can collect the signed price data from these sources and submit it to the contract.

The contract then checks whether the proposed price falls outside a pre-set deviation from the average of all upstream price sources.

If the proposed price exceeds the allowable range, the Oracle operator’s validator stake is slashed.

Upstream Price Source Security

If, for any reason, multiple upstream price sources begin to deviate significantly from established BTC prices available from other reliable sources, Oracle operators should temporarily halt price signings. This pause will give the governance system time to remove faulty upstream sources and propose new, reliable ones for the Oracle system.

DCA Security

The Distributed Collateral Agent (DCA) acts on behalf of the Lending Contract to sign necessary transactions; however, it’s important to clarify that it doesn’t have control over the Lending Contract or the Collateral Vault. The funds supplied by lenders remain non-custodial and securely held within the smart contract. The DCA’s role is limited to temporarily holding liquidated assets (BTC collateral) for auction purposes. To reduce risk, these liquidated assets must be sold as quickly as possible.

The DCA essentially functions as an agent managing the bad debt of liquidity providers. Allowing liquidity providers to nominate the DCA aligns interests and fosters trust. This nomination and selection process occurs periodically, with voting power weighted by the amount and type of LP tokens held. Crucially, the DCA and the Oracle (managed by 21 Side Chain validators) must remain separate entities.

Any misconduct by DCA operators will lead to penalties, including potential removal from the DCA role.

Additionally, all DCA operators must comply with Know Your Customer (KYC) requirements. This ensures all operators are properly vetted and held accountable for their actions within the network.