ERC-4337 Session Keys and EIP-7702: Bounded Authority for DeFi Agents

TLDR: Safe autonomous DeFi does not require handing an LLM a master private key. ERC-4337 gives smart accounts programmable validation around UserOperation objects, while EIP-7702 lets an EOA delegate its account code to an implementation without moving assets to a new address. Session keys are a wallet/module design built on top of those primitives—not a magic feature guaranteed by either standard. The secure pattern is explicit scope, value limits, target/function allowlists, expiry, replay protection, revocation, and independent policy/receipt verification.

Capability	Canonical status
spot.USER_SIGNED	operational
spot.BOUNDED_AUTONOMOUS	operational
futures.USER_SIGNED	operational
futures.BOUNDED_AUTONOMOUS	operational
solana.USER_SIGNED	operational
solana.BOUNDED_AUTONOMOUS	operational
ERC4337_SERVER_SUBMISSION	preparation_only
GENERIC_SERVER_INTENT_EXECUTION	preparation_only
MEE	preparation_only
ACP	deployment_prerequisite

Read canonical readiness and live deployment/request gates before execution. These rows are conditional capability contracts, not funded-production proof. USER_SIGNED requires fresh human authorization. Bounded execution requires a separate revocable domain policy and customer-agent-local signature per action, plus exact identity, scope, validity, simulation/research, risk/budget and replay checks. Commercial access cannot supply signing authority; FarmDash never receives the customer key.

What Problem Does Bounded Delegation Solve?

A supervised wallet can approve every action manually. That is simple to reason about but does not fit every autonomous workflow.

The dangerous alternative is to give an agent unrestricted signing power.

Bounded delegation creates a third option:

• the owner keeps the root authority;
• a narrower key or authorization can act inside an explicit envelope;
• transactions outside the envelope fail;
• the authority expires or can be revoked.

The important security property is de-escalation of privilege.

ERC-4337: Programmable Account Validation

ERC-4337 defines account abstraction using a higher-layer object called a UserOperation.

Conceptually:

Agent / Wallet
   ↓ UserOperation
Bundler
   ↓
EntryPoint
   ↓
Smart Account validation
   ↓
Execution

The smart account controls its own validation logic.

That logic can support:

• owner signatures;
• multisig;
• recovery;
• spending limits;
• role-based permissions;
• session-key modules;
• paymaster rules.

A session key is therefore not synonymous with ERC-4337. It is one permission model a smart-account implementation or module can provide.

EIP-7702: Delegated Code for Existing EOAs

EIP-7702 adds the set-code transaction type 0x04.

Its authorization list contains tuples of:

[chain_id, address, nonce, y_parity, r, s]

A valid authorization causes the EOA's code to contain a delegation indicator pointing at the selected implementation.

The account address and assets remain in place.

That can let an existing EOA use smart-account-style behavior without first moving assets into a newly deployed account.

What EIP-7702 does not do

EIP-7702 does not itself define:

• a session-key schema;
• a spending-limit format;
• a DeFi allowlist;
• a FarmDash authorization contract;
• safe UI for arbitrary delegation.

Those permissions have to be implemented by the delegated account code or a standardized module system.

That distinction matters because the EIP explicitly warns that delegated code can have broad authority over the account. The wallet must treat the implementation being delegated to as security-critical.

What Should a Session Authority Contain?

A useful DeFi session policy usually needs more than an expiration timestamp.

Example conceptual envelope:

{
  "authority": "0xSESSION_KEY",
  "validAfter": 0,
  "validUntil": 0,
  "chains": [8453],
  "allowedTargets": ["0xAPPROVED_ADAPTER"],
  "allowedSelectors": ["0xFUNCTION"],
  "allowedAssets": ["0xUSDC"],
  "maxValuePerAction": "10000000",
  "maxCumulativeValue": "50000000",
  "maxSlippageBps": 50,
  "nonceDomain": "farmdash-session-v1",
  "revocationId": "session-..."
}

This is illustrative, not a published FarmDash on-chain ABI.

The production schema must come from the actual wallet/module implementation.

Why Target and Selector Allowlists Matter

A value limit alone is not enough.

A compromised session key with permission to spend 100 USDC could still send that value to an attacker if the destination is unrestricted.

A stronger policy binds:

• target contract;
• function selector;
• asset;
• recipient rules;
• maximum value;
• chain;
• time window.

For complex protocols, decode the action semantically rather than only matching the first four bytes.

Why Replay Protection Matters

Any reusable signed authorization needs a replay model.

Possible mechanisms include:

• account nonce;
• session nonce;
• operation nonce;
• consumed permit ID;
• validity window;
• chain/domain separation.

The exact design depends on the account system.

The key invariant is:

A previously authorized action cannot be repeated outside the user's intended semantics merely because the old signature is still available.

Spending Limits Need Economic Semantics

A validator that parses only transfer(address,uint256) is not a general DeFi spending-limit engine.

Value can move through:

• swaps;
• approvals;
• deposits;
• multicalls;
• permit-based transfers;
• lending;
• bridges;
• native value;
• nested account execution.

A production policy engine should understand the economic meaning of the permitted adapter or restrict execution to audited adapter contracts whose behavior is intentionally narrow.

Session Key Storage

The delegated/session private key is still a private key.

If an attacker steals it, they inherit every permission inside the active session.

Protect it with:

• hardware-backed signing where practical;
• KMS/HSM or dedicated signing service;
• encrypted local storage for lower-risk environments;
• strict process isolation;
• short-lived credentials;
• no logging;
• no prompt exposure;
• no inclusion in general LLM context.

“Bounded” means damage is constrained. It does not mean compromise is harmless.

Revocation

Revocation needs a tested, route-specific mechanism.

Examples can include:

• removing a session key from a module;
• invalidating a session nonce;
• rotating the smart-account module;
• expiring the authorization;
• clearing or changing EIP-7702 delegation.

Do not assume increasing an arbitrary nonce automatically revokes every delegated authority.

A kill switch should verify the resulting on-chain state before reporting the session revoked.

EIP-7702 Security Caveat

Delegating EOA code is powerful.

The implementation can execute in the authority account's context. A user should not sign a delegation simply because a dApp asks for it.

The safer model is:

1. wallet recognizes or verifies the implementation;
2. implementation/module is audited;
3. permission semantics are visible;
4. owner understands revocation;
5. session authority is narrower than root authority.

FarmDash should never ask an agent to treat an opaque 7702 authorization as a normal low-risk signature.

How Does This Fit FarmDash?

FarmDash's long-term autonomous model is compatible with bounded authority:

proposal
→ standing grant verification
→ policy
→ simulation
→ authority checks
→ trusted execution
→ receipt verification
→ reconciliation
→ audit

But architecture is not the same thing as current production availability.

Use the live FarmDash capability/status contract to determine whether a specific route currently supports:

• supervised per-action authorization;
• bounded sessions;
• preparation only;
• server-verified execution;
• autonomous delegated execution.

Do not describe a future mode as live before the runtime proves it.

Supervised vs. Autonomous Modes

Supervised

The user signs each state-changing action.

Benefits:

• strongest per-action awareness;
• simple revocation: refuse the next signature.

Trade-off:

• requires user presence.

Bounded autonomous

The user signs one explicit standing grant.

In the bounded model the customer agent may omit a fresh human prompt only inside that grant and when its runtime domain permits it. It still signs every action locally. Read the generated capability table above for spot, futures and ERC4337_SERVER_SUBMISSION: these are separate paths, not one shared rollout gate. A grant does not provide UserOperation construction, signing, bundler submission, or verified settlement; configured bundler infrastructure alone does not qualify public account/session authority.

Required controls include:

• policy envelope;
• value/spend caps;
• allowlists;
• session expiry;
• replay protection;
• pause/revoke;
• authoritative simulation where supported;
• receipt/finality verification;
• reconciliation;
• anomaly detection.

The user should be able to inspect the grant in plain language before enabling it.

What About Cross-Chain Sessions?

Do not assume one session key automatically governs every chain.

Cross-chain delegation introduces separate concerns:

• deployment/module state on each chain;
• chain-specific nonce/replay;
• bridge/messaging assumptions;
• differing token addresses;
• differing execution adapters;
• finality differences.

A multi-chain policy can share a logical parent grant while still requiring independently verifiable chain-local authority.

Comparison

Model	User presence	Root-key exposure	Programmable limits	Main risk
Per-action signature	every action	none to service	request-specific	signing fatigue / phishing
Smart-account session	initial grant	root remains with owner	strong, implementation-specific	session/module compromise
EIP-7702 delegated account + module	initial delegation/grant	root remains with owner	strong if delegated implementation enforces it	malicious or buggy delegate code
Raw private key in agent	none	full	mostly off-chain	catastrophic key compromise

The final row should be treated as an anti-pattern, not the default autonomous architecture.

Frequently Asked Questions

Does ERC-4337 standardize session keys?

No. ERC-4337 standardizes the UserOperation/EntryPoint account-abstraction flow. Session keys are implemented by account logic or modules.

Does EIP-7702 make an EOA a new account?

The address remains the same. EIP-7702 sets a delegation indicator so calls execute code from the delegated implementation in the EOA's context.

Is the EIP-7702 transaction type 0x05?

No. The set-code transaction type is 0x04. 0x05 is the EIP's authorization-signing magic value.

If a session key is compromised, is the wallet safe?

Only to the extent the session constraints are correctly implemented and enforced. An attacker can use every permission the compromised key still has until expiry or revocation.

Does a payment API key grant session authority?

No. Commercial API access, x402 payment, wallet authorization, and session delegation are separate security domains.

Can FarmDash autonomously execute every DeFi route with a session key today?

Do not infer that from this architecture guide. Check the live capability/status contract for the route's current authority and execution state.

Primary Specifications

• EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
• ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
• ERC-6900 modular smart accounts: https://eips.ethereum.org/EIPS/eip-6900

Treat example policy schemas in this guide as conceptual. Production authority must be derived from the deployed, audited account/module contract.