Smart Contracts architecture

byzantine-contracts repository contains the smart contracts of the Byzantine protocol, an infrastructure that abstracts away the technical complexity of a restaking offer.

Stakers can fully customize their restaking strategy by selecting their preferred restaking protocols and devising their AVS portfolio, without having to worry about how to interact with the different protocols.

Byzantine also allows the restaking of native ETH, and provides pre-created Distributed Validators to native restakers. This technology highly reduce the risk of slashing and inactivity penalties.

In this document, you will learn more about the protocol components and the interaction between them.

System Components

Auction

File	Type	Proxy
Auction.sol	Singleton	Transparent Proxy

Auctions are a part of the Byzantine Finance protocol to fairly and efficiently match stakers with operators in a framework that is beneficial for both of them. An auction is the event where the top few are selected to become part of a DV cluster.

The Obol technology is used for the creation of Distributed Validators.

Escrow

File	Type	Proxy
Escrow.sol	Singleton	Transparent Proxy

The Escrow contract serves as a secure holding area for funds sent by node operators when bidding in an auction. As long as operators hasn't won, they can withdraw their bid at any moment and be refunded the amount paid.

When an auction is run, the Escrow releases the amount of the winning bids to the StakerReward contracts. From that point on, it is no longer possible to withdraw the winning bids.

StakerReward

Coming soon.

StrategyModuleManager

File	Type	Proxy
StrategyModuleManager.sol	Singleton	Transparent Proxy

This contract is responsible for assigning a pre-created DV to stakers wanting to stake native ETH, ensuring a smooth restaking experience. It also allows a StrategyModule to be tradeable through the sale of its associated byzNft.

Data regarding the number of deployed StrategyModule, their owners, and NFTs are stored in the StrategyModuleManager.

StrategyModule

File	Type	Proxy
StrategyModule.sol	Instanced, deployed per-user	Beacon Proxy

The restaking strategy is devised in the StrategyModule. This contract aggregates different restaking protocols and abstracts their interactions.

ByzNft

File	Type	Proxy
ByzNft.sol	Singleton	Transparent Proxy

This contract mints a ByzNft every time a new Strategy Module is deployed. The ownership a ByzNft conveys the ownership of a StrategyModule.

Smart Contracts architecture

Byzantine Contracts Architecture

Explanation of the user flow and the interaction between the contracts:

1. Node operators made bids

   1. Node operators wishing to join a Distributed Validator make bids by interacting with the Auction contract. They then join the auction set and wait to win to have the right to join a Distributed Validator. Learn more about the Auction mechanisms.

   2. The bid price is locked in the Escrow contract. As long as the node operator hasn't won the auction, it is possible to withdraw the bid or update its parameters.

2. Staker deploys a new StrategyModule and stakes 32ETH

   1. A staker wanting to stake native ETH calls the StrategyModuleManager to ask for the deployment a new StrategyModule.

   2. The StrategyModuleManager effectively creates a new StrategyModule contract and provides the deposit-data of a pre-created DV so that the staker can directly deposit his ETH on the Beacon Chain.

   3. A new ByzNft is minted, associated to the newly created StrategyModule and given to the staker.

   4. In the meantime, the StrategyModuleManager triggers a new auction to pre-create a new DV for the next staker.

   5. The auction winners are selected and their bid price is released from the Escrow to the StakerReward contract to secure the stakers PoS rewards.

3. Staker devise his restaking strategy

   1. Now that the StrategyModule is deployed, and the ETH staked, the staker can start devising his restaking strategy.

   2. The StrategyModule calls restaking protocols and starts securing AVSs.