Eulerfinance
Eulerfinance V2 lets owners authorize operators for individual EVC sub-accounts.
Eulerfinance V2 lets an account owner delegate broad authority to an operator for a selected Ethereum Vault Connector (EVC) account. The operator can be an externally owned account (EOA) or a smart contract. Its permission covers account actions that accept EVC operator authentication, including withdrawals and borrowing. The owner retains control over operator grants and owner security modes. Separate sub-accounts can have different operators. Revocation stops an operator from using the removed permission, while earlier completed actions remain effective. That division distinguishes delegated account access from token allowances, collateral control, and ownership of the wallet.
Revoking EVC operator permission stops future use of that grant without reversing completed withdrawals or borrowing.
Binary Authority Within the Selected Account
An operator grant switches an address's permission on or off for a selected account, without imposing an action-by-action limit. Wherever a contract accepts EVC operator authentication, the authorized address can act for that account. Its scope can include actions that materially change assets and liabilities.
An operator may move vault shares, withdraw assets, create debt, and batch calls. Reviewing only the operator's intended task leaves out other account actions that the permission allows.
The owner keeps control of operator authorization and owner security modes. An authorized operator can revoke its own access, but cannot authorize other operators or change owner security modes.
Execution still requires a destination that accepts EVC operator authentication. Operator status does not make every external contract recognize the delegated authority or the relationship between a derived sub-account and its owner. Compatible integrations must support the relevant EVC account flow.
Sub-Account Identities Under One Wallet
The EVC gives one controlling wallet 256 account IDs, with separate collateral, controller, and liability state for each sub-account. Account 0 corresponds to the wallet's own address. The other account identities use derived addresses under that same owner, rather than separate signing keys.
Each identity allows a different collateral set or controller without combining every position into one account. Authorization for one sub-account does not automatically cover its siblings. Delegating only the accounts that a strategy needs limits where its operator can exercise that permission.
Four Forms of Account Authority
Wallet ownership, token allowance, operator authorization, and controller designation govern different powers over assets and positions. They can coexist within a lending arrangement, so examining a token approval alone leaves broader account permissions unexplained.
| Authority | Relevant Scope | What It Enables | Authority Boundary |
|---|---|---|---|
| Controlling wallet | Accounts that it owns | Account management and operator authorization | Owner security modes remain owner-only |
| Token allowance | Limited token spending | Spending within the granted allowance | Separate from EVC operator authorization |
| EVC operator | Selected account or sub-account | Actions accepting EVC operator authentication | The owner retains EVC administration and can revoke the grant |
| Liability controller | Enabled collateral of the borrowing account | Enforcement of the borrowing vault's rules | Can restrict collateral withdrawal or seize collateral during liquidation |
A borrowing account designates a liability controller, which may be its borrowing vault or another contract. That role enforces collateral requirements. Operator authorization concerns who can act for the account; controller authority concerns the rules governing its enabled collateral.
Vault Rules Still Govern Delegated Actions
Operator authentication establishes who may perform a supported account action; the vault and controller determine whether that action satisfies lending requirements. A withdrawal remains subject to available vault liquidity and contract limits. Borrowing requires accepted collateral and must satisfy the liability vault's configured account checks.
Those checks include borrow loan-to-value (LTV), liquidation LTV, caps, and oracle-based valuation. The EVC can batch compatible calls, with final account checks still applying.
EulerSwap Pools as Contract Operators
EulerSwap uses a pool contract as an operator for the liquidity provider's Euler account. The provider authorizes that pool, and the factory requires the authorization before it will deploy the pool.
During a swap, the pool draws supplied inventory from the account's lending vaults. Where the configuration permits borrowing, it can borrow the remaining output against the account's collateral.
The pool supplies liquidity just in time without holding reserves itself. Its operator role connects the trading contract to the provider's lending position.
The owner retains EVC administration throughout this arrangement. Revoking the pool's operator authorization is the mechanism for decommissioning it.
Revocation Leaves Completed Actions Intact
The owner can revoke an operator's authorization for the selected account through the applicable EVC action. Revoking EVC operator permission does not reverse actions that the operator has already completed. An existing borrowing position still carries its debt.
Repaying debt or managing remaining collateral uses the account's position-management functions and their constraints. Revocation alone does not restore withdrawn assets or unwind previous share movements. Permissions that the same operator holds for other sub-accounts remain separate.
Funding Limits for Derived Addresses
Derived sub-account addresses other than account 0 have no private key and cannot sign ordinary transactions. ETH sent directly to them is permanently unrecoverable. Ordinary ERC-20 token recovery from those addresses depends on a reviewed EVC-aware flow for the exact token and integration. The owner can move shares issued by Euler Vault Kit (EVK) vaults through the EVC. Fund sub-accounts through the app or an EVC-aware integration. Operator permission does not provide a private key for a derived address.
Position Isolation and Shared Dependencies
Separate sub-accounts can keep unrelated operators and strategies from sharing the same account permission. That boundary follows the grants: a shared operator can affect each account that authorizes it. Compromise of the controlling wallet can also affect every account under its control.
Position separation leaves common market dependencies in place. Different sub-accounts may use the same vaults, oracle routes, or lending markets, so an account boundary does not remove those exposures. Review each delegated position alongside the wallet's aggregate exposure.
Permission Review During Position Management
Permission review starts with the operator address, selected sub-account, network, and intended actions. The address identifies the EOA or contract receiving authority; the account identifies the position that authority can affect. Check the applicable revocation method before granting access.
Monitoring needs to cover delegated activity and the underlying position. Review changes to vault shares, withdrawals, debt, and any account settings that the operator can affect. Remove permissions that no longer serve a strategy through the applicable owner action. An operator that remains authorized can continue exercising its supported account powers.
Popular questions about Eulerfinance
Can EVC Batching Span More Than One sub-account?
An EVC-aware integration can batch supported actions across sub-accounts. Every action still needs suitable authentication, and the batch must satisfy applicable controller rules and final account checks. Permission for one sub-account does not supply authorization for another. The integration must support the intended combination of actions; EVC batching alone does not establish that a particular interface offers it.
Does a Batched Transaction Still Need Token Approval?
Token approvals or permits can remain necessary when the app batches compatible position actions. The app can combine those actions into one atomic transaction, while an approval or permit may still require a separate wallet prompt. Batching does not remove applicable token-authorization requirements or final account checks.
Will Operator Authorization Activate stop-loss or take-profit Orders?
Granting operator access alone does not create stop-loss or take-profit functionality. The permission system can support implementations of automated trading and position management, but a service must implement the particular strategy. Those possibilities do not establish that every operator or the Euler app offers those order types.
Which Account Holds a Borrowing Position Opened in the Euler App?
The Euler app generally opens each Borrow or Multiply position in a separate EVC sub-account. Direct deposits use the main wallet address, account 0. An operator grant therefore needs to match the account containing the intended position. The app manages sub-account selection during normal use, so the controlling wallet address alone does not identify every separate borrowing position.
Does protocol-level Monitoring Replace Oversight of an operator-managed Position?
Protocol-level monitoring does not replace oversight of an operator-managed position. Euler's platform-level monitoring targets critical implementation-level threats to protocol contracts. Curators and integrators handle individual vault and market monitoring, including oracle behavior, governance changes, liquidity, and positions. Review of delegated activity remains part of managing the underlying position, even when protocol components have undergone security reviews.