Roles with special permissions

Currently The PoEL system spans two networks:

  • The Ethereum chain, where the Ethereum-specific IntraLayer Vaults reside.

  • The Supra network, where the PoEL and iAsset modules handle iAsset creation, SUPRA delegation and reward distribution.

The roles with special permissions on both the Ethereum and Supra sides are outlined below.

This overview may be incomplete, contain errors or be outdated. For current information on roles and capabilities, refer to the project’s GitHub repository.

Roles on Ethereum

The primary role on the Ethereum side is the Admin. This role has distinct permissions across several contracts, including the IntraLayer Vault, the Token Bridge contract, and the Fee Operator contract responsible for fee calculations. All admin actions are currently executed by 16-member multisig, any change requires a 9-of-16 approval. Over time, some of these authorities are expected to be delegated or moved under Supra governance once that governance framework matures.

Role

Address(es)

admin

0xb09eE905aFfb96E4da95D50ed946cDa696C8FF1D

This system also uses the Hypernova Bridge for cross-chain message transmission. You can find more information about it HERE.

Vault-Side Multisig Administration

Within the vault contract, the Vault Admin functionalities include:

  1. Delegate Admin Capabilities: Transfer these admin privileges to another address. This allows for future governance evolution without redeploying contracts.

  2. Pause Vault Contract: Halts the Ethereum Vault(IntraLayer vault) contract, effectively pausing all token bridging operations originating from the system's Ethereum users.'

  3. Set Transfer and Vault Caps: Configure per-transfer amount limits and total vault capacity limits per token. This mitigates risk from large-scale exploits or imbalances by enforcing economic bounds on iAssets.

  4. Set Token Bridge Contract: Point the Vault to a new Token Bridge Service contract, used to rotate/upgrade the bridge.

  5. Emergency Withdrawal (Temporary Feature): Conduct withdrawals from the Ethereum Vault(IntraLayer vault) which holds users’ deposited underlying assets used only for crisis response or governance-approved migrations (e.g., when a future DFMM release requires replacing the current vault implementation):

    1. Process: Requires two sequential transactions: - Request Transaction: Initiates the withdrawal request. - Execution Transaction: Executes the withdrawal, transferring funds from the Vault to the specified destination address.

    2. Safeguard: Per the contract, execution is permitted after a minimum 1-week delay from the initial request, providing a window for community review and intervention.

  6. Upgrade Vault Implementation: Replace the Vault’s logic contract behind the proxy, updating functionality without changing the proxy address or stored state. Used to deploy fixes or new features while preserving asset balances and configurations.

Administrative Operations on the Token-Bridge Side

On the token-bridge(and hypernova) side, admin capabilities include:

  1. Transfer Admin Privileges: Delegate or transfer these Token Bridge admin privileges to another wallet address, enabling seamless transition of governance rights.

  2. Update Configuration Parameters: Modify bridge-specific settings(specific to PoEL system), such as transaction fees, to adapt to system conditions or economic models.

  3. Set Fee Operator and Vault Address: Assign/change the fee-logic operator. Controls fee calculation/validation used during transfers. Reconfigure which Vault contract holds locked funds.

  4. Set Native Token: Set Updates the bridge’s canonical native-token address (usually the wrapped native coin, e.g., WETH).

  5. Token Registration: Adding a new token on Ethereum requires coordinated approvals on both the Vault and the Bridge side. Admins can add or remove a token for bridging to a specific chain(specifying Uniswap V3 pool ID as price reference). Admin can also add or remove a token for bridging to a specific chain with fixed service/relayer fees.

  6. Register/Unregister Destination Chain: Enable or disable bridging to a specific chain, controlling which chains the system will service.

  7. Set Hypernova Endpoint: Point the bridge to a new Hypernova messaging/config contract, future operations reference this updated endpoint.

  8. Upgrade Implementation: Replace the bridge’s logic contract while preserving storage/state, enabling feature updates or fixes.

  9. Pause/Unpause Bridge: Toggle the global operational state, when paused, new bridge actions of the system are halted until re-enabled.

Admin Functions on the Fee-Operator Side

On the fee-operator side, admin capabilities include:

  1. Set Admin: Replace the Fee Operator’s admin address, transferring administrative control as protocol governance and management evolve.

  2. Set Hypernova Endpoint: Point the Fee Operator to a new Hypernova messaging/config contract. Future fee computations will reference the updated Hypernova config.

  3. Set S-Value Feed (+ Pair Index): Update the on-chain price feed source and the SUPRA/USDT pair index used in fee calculations. Affects conversion of relayer rewards and service fees into the bridged(applied as liquidity) asset units.

  4. Add or Update Transfer-Bridge Fee Config : Create or modify the fee configuration for the chains.

  5. Pause/Unpause Fee Operator: Toggle the global paused state of the contract, pausing halts operational fee computation.

Roles on the Supra Side

PoEL on the Supra side defines three roles:

  • Deployer - While not a formal PoEL role, the deployer can upgrade modules by publishing a new package version to the PoEL package address

  • Owner – The ultimate steward. Grants and revokes administrative powers, and authorizes movement of borrowable amounts into and out of the system. In the long run, once full network governance is live, this authority is expected to transition to (or be determined by) on-chain governance

  • Admin – Enables/disables features, updates configurations, and onboards new assets, etc. This role is expected to be assigned by the owner to the entity responsible for system administration.

  • Pool Manager – Operations role focused on selecting the delegation pools the PoEL system interacts with. In future versions, this authority is envisioned to be granted to a collective governance system, enabling iAsset holders to decide which pools receive delegation and which are replaced based on their expectations of validator performance.

Presently, all roles are assumed by multisig addresses with the similiar membership setup: a 16-member committee where 9 of 16 signatures are required for any administrative action.

Role

Address(es)

deployer

0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932

owner

0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932,

0xfcd4f9272b20ddc08bbd0614b3dda632930889ea9ba307574ec12d9273d9a3f2

admin

0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932

Pool manager

0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932

Owner Role

The Owner role on the Supra blockchain side includes:

  1. Emergency Withdrawal (Temporary Feature): Conduct withdrawals from the Supra vault(Intralayer vault)—which holds users’ deposited underlying assets— used only for crisis response or governance-approved migrations (e.g., when a future DFMM release requires replacing the current vault implementation). Process: It is 2 step process:

    1. Request Transaction: Initiates the withdrawal request.

    2. Execution Transaction: Executes the withdrawal, transferring funds from the Vault to the specified destination address.

  • Safeguard: Per the contract, execution is permitted after a minimum 1-week delay from the initial request, providing a window for community review and intervention.

  1. Appoint and Remove Admins and Owner: Add multisig addresses to the Admin set so they can perform operational tasks defined by the protocol. Revoke Admin access when it is no longer appropriate. (e.g., key rotation, role changes, or security concerns). The deployer also has the exclusive right to designate other owners.

  2. Appoint and Remove Pool Manager: Granting or revokes the Delegation Pools role for specified addresses.

  3. Set the Withdrawal Address: Update the address that receives withdrawn SUPRA (e.g., when decreasing borrowable amounts or withdrawing surplus rewards).

  4. Update Oracle Pair IDs: Refresh the price-oracle pair IDs for selected iAssets to keep pricing and indexation current.

  5. Increase Borrowable Capacity: Transfer SUPRA into the PoEL vault to raise the protocol’s total borrowable amount.

  6. Decrease Borrowable Capacity: Reduce the protocol’s total borrowable amount, immediately forwards available principal to the withdrawal address and schedules any shortfall to be unlocked from delegation pools.

  7. Withdraw Surplus Rewards: Send excess staking-reward proceeds (not principal or rewards not allocable to users) from the PoEL vault to the withdrawal address.

Admin Role

The functions covered by Admin role include:

  • Set Service-Fee Address: Update the address that receives the protocol’s service-fee charged in iAssets.

  • Set Stimulus Rewards-Distribution Address: Update the address that receives withdrawn stimulus reward funds.

  • Enable/Disable Reward Allocation: Turn the rewards-allocation process on or off.

  • Update System Parameters: Modify global settings, including collateralization rate related coefficients, epoch length, lockup-cycle length, APY window (in epochs), reward-reduction rate, per-pool max delegation cap, smallest distributable-rewards portion, minimum rewards threshold to distribute, minimum allocation frequency, and lockup cycle length (in epochs)

  • Change verification policy: Update the method used to verify cross-chain messages and adjust its safety level, applies to future message processing.

  • Pause or resume operations: Temporarily halt or resume processing of incoming bridge messages to manage incidents or maintenance.

  • Initialize Delegation Pools: Register the initial set of validator delegation pools used by PoEL.

  • Create New iAsset: Deploy a new iAsset (name, symbol, pair ID, metadata, and source-bridge details) in the system

  • Update Desired Weights: Adjust per-iAsset target weights in the liquidity portfolio that inform collateralization-rate calculations.

  • Update Desirability Scores: Tune per-iAsset desirability scores that influence reward distribution proportions. Desirability weights are intended to be tuned algorithmically by a separate module in the future. .

  • Pause/Unpause an iAsset: Temporarily halt or resume actions for a specific iAsset.

  • Set Redeemable Flag: Enable or disable redemption for a specific iAsset.

  • Freeze/Unfreeze Account: Block or restore a specific user’s ability to interact with a given iAsset.

  • Update Capital-Efficiency Coefficient: Set the coefficient used in reward-allocation math to modulate effective rewards based on capital efficiency. Capital-Efficiency Coefficient is intended to be tuned algorithmically by a separate module in the future.

  • Set Service Fees : Configure global protocol fees for Supra-native assets used as underlying liquidity, deposit , redeem on Supra, and redeem to external chains.

  • Register Supported Assets: Add a fungible asset (FA native to Supra)) to the list of collateral iAssets allowed for deposits/withdrawals.

  • Deregister Assets: Remove an FA(native to Supra) from the supported list, preventing new deposits/withdrawals for that asset.

  • Set Per-Asset Deposit Limit: Define or update a deposit cap for a specific FA. Enforced during deposit flow.

  • Enable/Disable Deposits: Toggle whether the system accepts any deposits across Supra native assets submitted as liquidity to intralayer vaults.

  • Enable/Disable Withdrawals: Toggle whether withdrawals are allowed across Supra native assets submitted as liquidity to intralayer vaults.

Pool Manager Role

  • Submit Delegation-Pool Replacement Request: Propose removing a currently-used delegation pool from the PoEL system. Triggers an unlock of that pool’s active stake and records the request for processing after the lockup cycle ends.

  • Execute Delegation-Pool Replacement: After the relevant lockup cycle completes, withdraw the unlocked stake from the old pool and delegate it to the new pool.

Last updated