# Roles with special permissions

Currently The PoEL system spans two networks:&#x20;

* 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.&#x20;

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

{% hint style="info" %}
This overview may be incomplete, contain errors or be outdated. For current information on roles and capabilities, refer to the project’s [GitHub repository](https://github.com/Entropy-Foundation/IntraLayer/).
{% endhint %}

### 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.&#x20;

| **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](https://supraoracles.gitbook.io/supra/supranova/).

### 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.&#x20;
4. **Set** **Token** **Bridge** **Contract**: Point the Vault to a new Token Bridge Service contract, used to rotate/upgrade the bridge.&#x20;
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.&#x20;
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&#x20;

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.&#x20;

### 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.&#x20;

| Role         | Address(es)                                                                                                                                         |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| deployer     | 0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932                                                                                  |
| owner        | <p>0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932,</p><p>0xfcd4f9272b20ddc08bbd0614b3dda632930889ea9ba307574ec12d9273d9a3f2</p> |
| admin        | 0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932                                                                                  |
| Pool manager | 0xda20f7d0ec813c751926f06004a10bc6ee1eefc96798f6a1aa31447ee146f932                                                                                  |

{% hint style="success" %}
**Below, we break down the capabilities of contract defined roles .**
{% endhint %}

#### Owner Role&#x20;

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.<br>

2. **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.&#x20;
3. **Appoint** **and** **Remove** **Pool** **Manager**: Granting or revokes the Delegation Pools role for specified addresses.&#x20;
4. Set the **Withdrawal** **Address**: Update the address that receives withdrawn SUPRA (e.g., when decreasing borrowable amounts or withdrawing surplus rewards).
5. **Update** **Oracle** **Pair** **IDs**: Refresh the price-oracle pair IDs for selected iAssets to keep pricing and indexation current.
6. **Increase** **Borrowable** **Capacity**: Transfer SUPRA into the PoEL vault to raise the protocol’s total borrowable amount.
7. **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.
8. **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&#x20;

The functions covered by Admin role  include: <br>

* **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.&#x20;
* **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.&#x20;
* **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&#x20;

* **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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://supraoracles.gitbook.io/supra/proof-of-efficient-liquidity-poel/roles-with-special-permissions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
