Byzantine Vault Parameters

This page documents the full list of initialization parameters specific to a Byzantine Vault entity. All the Byzantine Vaults must establish these structure of settings beforehand creation.

ByzVaultParams

Parameter	Type
token	address
roleManager	address
versionManager	address
depositWhitelistManager	address
depositLimitManager	address
curatorFeeClaimer	address
curatorFeeClaimerRoleAdmin	address
curatorFee	number
depositLimit	boolean
isDepositLimit	boolean
isPrivateVault	boolean
isTokenized	boolean
name	string
symbol	string
metadataURI	string

Breaking down the parameters

token

The ERC20 token to be deposited into the vault - the collateral token.

• For native ETH, use the canonical address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.

• For Eigen vaults, make sure the token address is whitelisted or has a corresponding EigenLayer Strategy (if not the transaction will revert).

---

roleManager

This address holds the highest level of authority and is the most powerful within the system. It must be highly trustworthy, and it is strongly recommended to use a high-threshold multi-sig to ensure robust security.

• This address holds the DEFAULT_ADMIN_ROLE and has the authority to grant and revoke any of the vault's roles - with no adminRole explicitly set - to any addresses.

• This role holder can also renounce the role, blocking the addition of new curator addresses.

• Can be set to address(0) to prevent the addition of new curator addresses after deployment. In this case, the vault creator must ensure that all necessary roles are assigned at creation to guarantee proper vault functionality.

---

versionManager

This address manages the implementation version of the Byzantine Vault and its underlying vaults.

• This address can:

  • upgrade the Byzantine Vault to a newer implementation that has been whitelisted by Byzantine

  • update the metadata URI of the vault`

  • migrate the underlying Symbiotic vault to a newer version (only if an underlying Symbiotic Vault exists)

• This role can be managed by the roleManager (if any)

---

depositWhitelistManager

This address manages the whitelist of depositors / stakers and can change the vault's accessibility.

• This address can:

  • add / remove addresses from the deposit - staker - whitelist

  • set / change the vault from public to private or vice versa

• If the vault is public, whitelisting depositors - stakers - will revert.

• Can be set to address(0) if isPrivateVault is false, in case the creator plans to let anyone deposit
• This role can be managed by the roleManager (if any)

---

depositLimitManager

This address manages the maximum number of tokens that can be deposited in the vault.

• This address can:

  • set / change the vault's depositLimit
  • enable / disable the isDepositLimit status

• If isDepositLimit is false, the depositLimit will not be taken into account.
• Can be set to address(0) if isDepositLimit is false, in case the creator does not plan to cap the vault.

• This role can be managed by the roleManager (if any)

---

curatorFeeClaimer

This address can claim the curator fee from the restaking rewards accrued by the vault.

• Only the curatorFeeClaimerRoleAdmin can manage this role (if set)

---

curatorFeeClaimerRoleAdmin

This address manages the CURATOR_FEE_CLAIMER_ROLE holders and can change the curatorFee post deployment.

• This address can:

  • grant the CURATOR_FEE_CLAIMER_ROLE to new addresses

  • revoke the CURATOR_FEE_CLAIMER_ROLE from an address

  • change / adjust the curatorFee
  • renounce the role, and therefore blocking the addition of new curator fee claimers.

---

curatorFee

The curator fee taken from the accrued restaking rewards (in percentage).

• Expressed in basis points:

  • 500 represents 5%,

  • 10_000 represents 100%.

---

depositLimit

Maximum number of assets that can be deposited into the vault.

• Only enforced when isDepositLimit is true.
• If isDepositLimit is enabled - true - and depositLimit is not set, the value defaults to 0 and new deposits will be rejected. In other words, the curator must set a depositLimit if the vault requires one, otherwise it won't be possible to deposit.
• Can only be modified by the depositLimitManager.

---

isDepositLimit

Determines whether the vault has a cap or not.

• If true, the vault will not accept new deposits who exceed depositLimit.

• If false, an infinite number of assets can be deposited (theoretically).

• Can only be modified by the depositLimitManager.

---

isPrivateVault

Defines the vault's accessibility.

• If true, only the addresses that are whitelisted - set to true in the canDeposit mapping - are allowed to deposit into the vault

• Can only be modified by the depositWhitelistManager.

---

isTokenized

Whether the Byzantine vault shares are transferable or not.

• If true, the vault shares can be transfered to other addresses or contracts. It makes the vault composable in the DeFi space.

Accumulated restaking rewards cannot be transferred with the shares. Rewards can only be claimed by the shares holder at the time of the distribution.

---

name

The name of your Byz Vault Shares.

---

symbol

The symbol of your Byz Vault Shares.

---

metadataURI

URI pointing to the off-chain metadata associated with the vault.

• Can only be updated by the versionManager.
• This value is not stored on-chain; only an event is emitted.

• Refers to the below section to learn how to generate vault's metadata URI

How to generate metadata URI

We expect the URI to point to a JSON object that follows a specific structure. This ensures consistent display of metadata across the app and makes it easier for others to interpret and use it as well.

To achieve this, please follow the structure below:

interface Metadata {
  name: string; // Required
  description: string; // Required
  social_twitter?: string;
  social_discord?: string;
  social_telegram?: string;
  social_website?: string;
  social_github?: string;
}

Only name and description are mandatory. The other fields are optional and allow you to share more context with your users.

Note that, although initially set at creation, the metadata can be updated at any time by the versionManager by calling updateMetadataURI(metadataURI)

There is two ways of generating Metadata URI, with the vault's SDK or the Pinata interface. Choose the method that best suits your setup:

Byzantine SDK

1. Install Byzantine SDK

npm install @byzantine/vault-sdk@latest

1. Generate a Pinata API key (if you don't already have one) and setup your .env file

// Fill your .env file
PINATA_API_KEY = 
PINATA_SECRET_API_KEY = 

1. Write your code

// Import Byzantine SDK
import { convertMetadataToURI, Metadata } from "@byzantine/vault-sdk";
import * as dotenv from "dotenv";
dotenv.config();

const metadata: Metadata = {
  name: "Eigenlayer ETH Vault",
  description: "An Eigenlayer vault for ETH restaking"
};

const uri = await convertMetadataToURI(metadata);

console.log("uri:", uri); // This will print your URI!

1. Run the command

npx tsx index.ts # If using typescript
# or
node index.js # If using Javascript

Pinata interface

1. Create a file that respect the type above. Let's call it metadata.json , but the name doesn't change anything.

2. Go to https://app.pinata.cloud/ipfs/files
3. Click on Add -> File Upload -> [Select your file] -> Upload

1. Get the CID

1. Convert it into a link https://gateway.pinata.cloud/ipfs/[CID]

So bafkreiaprhnvhh54ppa2whrb7blfvqtdgzuuojssogibr3ssibgayhlz6y becomes https://gateway.pinata.cloud/ipfs/bafkreiaprhnvhh54ppa2whrb7blfvqtdgzuuojssogibr3ssibgayhlz6y

That's your URI!