Developer Docs
WebsiteGitHub
  • Protocol Architecture
    • Protocol Overview
    • Upgradability
    • Asset Configuration
    • Silo Assets
    • Bridge Assets & Bridge Pool
    • System Roles
  • Smart Contracts Overview
    • Core Protocol
      • SiloRepository
      • Silo
    • Oracle
      • PriceProvidersRepository
      • BalancerV2PriceProvider
      • UniswapV3PriceProvider
    • Ownership Tokens
      • ShareCollateralToken
      • ShareDebtToken
    • InterestRateModel
    • SiloRouter
    • SiloLens
  • SECURITY
    • Audits & Formal Verification
    • Smart Contracts
    • Bug Bounty Program
  • Silo Subgraphs
    • Subgraph Introduction
    • SILO V2 Entities
    • SILO V3 Entities
    • Querying SILO
  • Submit a Bug
  • GitHub
  • Silopedia
  • Contact Us
Powered by GitBook
On this page
  1. Protocol Architecture

Bridge Assets & Bridge Pool

PreviousSilo AssetsNextSystem Roles

Last updated 1 year ago

On the Silo protocol, assets are divided into two classes: silo and bridge assets. From the technical perspective, there is no difference. All assets are the same ERC-20 compatible tokens. The difference is in how these assets are used in the protocol. When creating a silo, we need to specify for which asset it is created for. This asset will be a "silo asset". But technically, we can't create a silo with a single asset. In that scenario, it loses any practical value for the protocol - a bridge asset is required for a silo to function. Let's take a look at an example for a better understanding. SiloRepository has one bridge asset registered: WETH. We create two silos: LINK and DAI.

Each silo can have only one "silo asset" and multiple bridge assets. Management of the bridge assets happens in the Silo Repository where an authorized party (governance) can add/remove bridge assets. After adding/removing bridge asset, each Silo must be synchronized.

Synchronization occurs automatically during silo creation and manually after that. The method for the bridge assets synchronization is public and open to anyone which means that at any point in time, any user can synchronize bridge assets into the silo.

The synchronization process can affect a silo in two ways: adding or removing the bridge assets. When the bridge asset is added to the silo, users will be able to deposit it and borrow any other asset in the silo using it as collateral.

On the other hand, if existing in the silo, the bridge asset will be removed its functionality will be limited. Such features as "deposit" and "borrow" will be disabled. While "withdraw" and "repay" will still work. It can happen that the removed bridge asset will be added again. In that case, it should work as any other asset. If there are two or more bridge assets in the protocol, it opens a possibility to create a "bridge pool". This pool is similar to any other silo in the protocol and behaves in the same way. The only difference is that we can create only one "bridge pool" in the protocol, and it contains only the bridge assets. The bridge asset for which this silo was created will become a "silo asset" in that silo.

To better understand, see application state visualization while bridge assets are added/removed, and bridge pool is created.

Bridge asset in the silo
Bridge pool
Application state
Actions notes