Symbiotic Protocol is an extremely flexible and permissionless shared security system.
This repository contains the core Symbiotic smart contracts responsible for managing deposits, stake allocations and slashing.
Symbiotic core consists of:
-
Collateral: a new type of asset that allows stakeholders to hold onto their funds and earn yield from them without needing to lock these funds in a direct manner or convert them to another type of asset.
-
Vaults: the delegation and restaking management layer of Symbiotic that handles three crucial parts of the Symbiotic economy: accounting, delegation strategies, and reward distribution.
-
Operators: entities running infrastructure for decentralized networks within and outside of the Symbiotic ecosystem.
-
Resolvers: contracts or entities that are able to veto slashing incidents forwarded from networks and can be shared across networks.
-
Networks: any protocols that require a decentralized infrastructure network to deliver a service in the crypto economy, e.g., enabling developers to launch decentralized applications by taking care of validating and ordering transactions, providing off-chain data to applications in the crypto economy, or providing users with guarantees about cross-network interactions, etc.
- Git (installation)
- Foundry (installation)
Clone the repository
git clone --recurse-submodules https://github.com/symbioticfi/core.git
Open DeployVaultV2.s.sol, you will see config like this:
// Name of the ERC20 representing shares in the vault
string NAME = "SymVault";
// Symbol of the ERC20 representing shares in the vault
string SYMBOL = "SV";
// Address of the owner of the vault who can migrate the vault to new versions whitelisted by Symbiotic
address OWNER = 0x0000000000000000000000000000000000000000;
// Address of the vault asset token
address ASSET = 0x0000000000000000000000000000000000000000;
// Optional
// Deposit limit (maximum amount of assets allowed in the vault)
uint256 DEPOSIT_LIMIT = 0;
// Whether deposits are restricted to whitelisted depositors
bool DEPOSIT_WHITELIST = false;
// Initial whitelisted depositor (used only when DEPOSIT_WHITELIST is true)
address DEPOSITOR_TO_WHITELIST = 0x0000000000000000000000000000000000000000;Edit needed fields, and execute the script via:
forge script script/DeployVaultV2.s.sol --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> --broadcast
In the console, you will see logs like these:
Deployed VaultV2
vault:0x9c9e536A269ec83a0628404e35b2F940d7226c8C
delegator:0xb7a105A294f7E2d399C9692c12ba4cAba90F5AABThere are predefined V2 action-scripts, that you can use from the start:
- AddAdapter – add an adapter to a VaultV2 delegator
- RemoveAdapter – remove an adapter from a VaultV2 delegator
- SwapAdapters – swap two adapters in a VaultV2 delegator
- AllocateAdapter – allocate assets to one adapter
- AllocateAdapterExact – allocate an exact amount to one adapter
- AllocateAdapters – allocate assets across configured adapters
- DeallocateAdapter – deallocate assets from one adapter
- DeallocateAdapters – deallocate assets across configured adapters
- DeallocateAdaptersExact – deallocate an exact amount across configured adapters
- ForceDeallocateAdapter – force deallocation from one adapter
- SweepPending – settle pending adapter deallocations
- SetAdapterLimit – set an adapter absolute limit
- SetAdapterLimits – set adapter absolute and share limits
- SetAutoAllocateAdapters – configure auto-allocation adapters
- RequestRedeem – request a VaultV2 withdrawal
- ClaimWithdrawal – claim a finalized VaultV2 withdrawal
- SetDepositLimit – set the VaultV2 deposit limit value
- SetIsDepositLimit – enable or disable the VaultV2 deposit limit
- SetDepositWhitelist – enable or disable the VaultV2 deposit whitelist
- SetDepositorWhitelistStatus – whitelist or unwhitelist a depositor
- SetManagementFee – set the VaultV2 management fee and receiver
- SetPerformanceFee – set the VaultV2 performance fee and receiver
Interaction with different actions is similar; let's consider SetAdapterLimits as an example:
-
Open SetAdapterLimits.s.sol, you will see config like this:
// Address of the VaultV2 address constant VAULT = address(0); // Address of the adapter to configure address constant ADAPTER = address(0); // Absolute adapter limit uint256 constant ABSOLUTE_LIMIT = 0; // Relative adapter share limit uint256 constant SHARE_LIMIT = 0;
-
Edit needed fields, and execute the operation:
-
If you use an EOA and want to execute the script:
forge script script/actions/v2/SetAdapterLimits.s.sol --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> --broadcast
-
If you use a Safe multisig and want to get a transaction calldata:
forge script script/actions/v2/SetAdapterLimits.s.sol --rpc-url <RPC_URL> --sender <MULTISIG_ADDRESS> --unlocked
In the logs, you will see the action fields and a simulation link like this:
Set adapter limits vault:0x9c9e536A269ec83a0628404e35b2F940d7226c8C adapter:0x7a7ED2F93D071838b426d9aeC0368e2eB3bfE1D5 absoluteLimit:1000000000000000000000 shareLimit:500000 Simulation link: https://dashboard.tenderly.co/TENDERLY_USERNAME/TENDERLY_PROJECT/simulator/new?network=1&contractAddress=0xb7a105A294f7E2d399C9692c12ba4cAba90F5AAB&from=0x2aCA71020De61bb532008049e1Bd41E451aE8AdC&rawFunctionInput=0x...In Safe->TransactionBuilder, you should:
- enable "Custom data"
- enter the simulation link
contractAddressas a target address - use the simulation link
rawFunctionInputas aData (Hex encoded)
-
Moreover, a Tenderly simulation link is provided as an additional safeguard, e.g.:
Simulation link:
https://dashboard.tenderly.co/TENDERLY_USERNAME/TENDERLY_PROJECT/simulator/new?network=1&contractAddress=0xb7a105A294f7E2d399C9692c12ba4cAba90F5AAB&from=0x2aCA71020De61bb532008049e1Bd41E451aE8AdC&rawFunctionInput=0x...forge build
forge test
forge fmt
Configure environment
Create .env based on the template:
ETH_RPC_URL=
ETHERSCAN_API_KEY=
Security audits are aggregated in ./audits.