Skip to main content

Burners

Description​

Symbiotic protocol allows the use of any asset to provide economic security. However, one condition is that the assets must be represented as ERC-20 tokens. Such possible assets are:

  1. Governance tokens
  2. ETH LSTs
  3. DEX LP tokens
  4. Wrappers for tokens from networks other than Ethereum
  5. RWA tokens
  6. ...

Let’s assume a standard staking design - the operator misbehaves, and its collateral is burnt. Therefore, for each ERC-20 token used as collateral, it should be possible to burn its underlying asset. In general, there are 2 ways how to handle such behavior from the protocol side:

  1. 🔴 Create a new standard interface for the slashing, which the collateral tokens should support. However, this solution is inconvenient for the existing tokens as it adds an obligatory wrapper over them.
  2. 🟢 Allow the creation of external contracts, whose responsibility is to process the slashing using the received slashed tokens. This solution leaves much more flexibility over the slashing process without any add-ons for the existing tokens. And such contracts are named - burners.

burners

Technical overview​

Symbiotic core contracts don’t force the use of some specific burners. Therefore, anyone can create their own implementation of it.

note

The burners can be created by anyone. However, only the Vault curators are able to set the burners for their Vaults.

warning

The burner is set in the Vault during its initialization and cannot be changed later.

Considering the assets listed above, let’s see how to actually process them in case of slashing using the burners:

  1. Governance tokens - Just burn (or, similarly, send to some dead address). burners-governance
  2. ETH LSTs - They represent staked ETH on the Beacon Chain. Therefore, it is necessary to withdraw this ETH first and then burn it. burners-lst
  3. DEX LP tokens - They represent a set of tokens that provides liquidity for exchanges. Hence, each of these tokens should be unwrapped and burnt. burners-lp
  4. Wrappers for tokens from networks other than Ethereum - This case is similar to the ETH LSTs’ one. Need to unwrap the wrapper on Ethereum and burn the token on the other network. burners-other-network
  5. RWA tokens - They represent some assets from the real world and, therefore, some real assets should be destroyed. (?) burners-rwa

Other processing mechanics​

As mentioned above, in a standard staking and burning mechanic, the RWA should be destroyed (a.k.a. burned). Let’s assume that the RWA token is represented by real estate; then, destroying the real estate object is necessary. However, it doesn’t seem practical. Hence, there could be some other possible processing mechanics of the slashed collateral:

  1. Redistribution to good operators burners-good-ops
  2. Redistribution to victims (in case of using the staking more as a security deposit) burners-victim
  3. Lock as LP burners-lp-lock
  4. ...
warning

In general, burning the slashed funds is one of the safest ways to go. Any other methodology for processing the slashed funds may create incentives for different parties to trigger the slashing, depending on many factors.

From the examples above, it can be seen that the burner is only a single address that receives the slashed collateral tokens. As a consequence, e.g., in case of redistribution needs, it is impossible for networks to have separate distribution contracts for each network directly. Therefore, we allow burners to receive an onSlash() call on each slashing event, which makes it possible to account for the amounts of slashed funds by each network.

info

To turn on the on-slash callback mechanic, set Slasher.BaseParams.isBurnerHook equal to true on initialization.

Burner Router​

Code can be found here

Using the on-slash callback functionality mentioned above, we provide a ready-to-go BurnerRouter contract, allowing Vault curators and networks to configure a needed granular and updatable configuration of slashed collateral receivers depending on the slashing networks and the slashed operators.

Its workflow is the following:

  1. Set (or update with delay) the configuration of receivers (which can be represented, e.g., by burners or by treasury addresses)
  2. During the slashing event, the contract is called via onSlash() function, which determines the needed receiver given the slashing networks and the slashed operators, and increases its balance
  3. The transfer of the collateral tokens to the receiver is triggered via triggerTransfer()
info

Only a single vault should use the same BurnerRouter contract simultaneously.

burners-router

Default Burners​

Code can be found here

We provide default implementations of simple burners for several ETH LSTs we collect pre-deposits. These are immutable pure contracts that can be used within the router and whose flow, in general, is:

  1. Create a withdrawal request
  2. Complete a withdrawal request receiving the underlying ETH
  3. Burn ETH
info

An unlimited number of vaults can use the same DefaultBurner contracts.

LST    Code link                                                                                        
wstETH  wstETH_Burner.sol
rETH    rETH_Burner.sol  
mETH    wstETH_Burner.sol
swETH  swETH_Burner.sol
sfrxETHsfrxETH_Burner.sol
ETHx    ETHx_Burner.sol