Designing Dual-Checkpoint Spending Guards for ERC-4337 AI Agents: API Pre-Check + On-Chain Session Enforcement

In autonomous Web3 architectures, delegating on-chain execution to AI agents using standard Externally Owned Accounts (EOAs) creates catastrophic tail risks, while traditional multi-sig contracts block automated workflows. Single-layer defenses fail in production: pure off-chain API rate limits are vulnerable to concurrent race conditions and key bypass, whereas pure on-chain checks incur prohibitive gas penalties on rejected UserOperations. The production-proven defense is a Dual-Checkpoint Spending Guard: an off-chain API gateway enforcing atomic PostgreSQL row-level locks (SELECT ... FOR UPDATE) over strict UTC day buckets and raw integer token units, paired with an immutable ERC-4337 execution guard contract enforcing session validity, function selector whitelisting, recipient restrictions, and independent on-chain daily accumulation.

1. The Production Failure State: Why Autonomous Agents Drain Single-Layer Wallets

When an LLM agent operating in an automated environment encounters unexpected tool output—such as a downstream HTTP 504 gateway timeout or an ambiguous JSON payload—its default behavioral tendency is to retry. If that agent holds the private key to an EOA or an unconstrained ERC-4337 session key, a retry loop is not merely a software bug; it is a direct financial drain.

Consider a real failure mode observed in multi-agent orchestration systems:

[02:14:02.105Z] Agent Worker #1: Dispatches payment for 40 USDC (Tool Call: compute_task_order_A)
[02:14:02.112Z] Agent Worker #2: Dispatches payment for 40 USDC (Tool Call: compute_task_order_B)
[02:14:02.118Z] Agent Worker #3: Dispatches payment for 40 USDC (Tool Call: compute_task_order_C)
---------------------------------------------------------------------------------------------------
Daily Budget Cap Configured: 100 USDC (100,000,000 raw units)
Expected Behavior: Worker #1 and #2 succeed; Worker #3 rejected (80 + 40 = 120 > 100)
Naive API Check: 3 parallel SELECT sum(amount) queries all read `spent = 0` at t=0
Actual Result: All 3 UserOperations signed and submitted; total drained = 120 USDC. Budget breached.

In a traditional web application, an overdraft results in a rejected credit card authorization or a negative ledger balance that can be clawed back. On a public blockchain (such as Base, Arbitrum, or Ethereum L1), transactions confirmed by the consensus engine are irreversible.

Three naive approaches to this problem invariably collapse under production loads:

1. Giving the Agent an EOA Private Key: The agent signs transactions directly. There is zero execution-time policy control. A prompt injection attack or an unconstrained reasoning loop can transfer the entire wallet balance in a single transaction.
2. Standard Multi-Sig (e.g., Safe without automated modules): Every transaction requires human cryptographic signatures. This breaks the fundamental value proposition of autonomous AI agents, reducing autonomous pipelines to manual ticketing queues.
3. Pure Off-Chain Middleware (API-Only Limits): The application checks a database before handing the signature to the agent. This introduces a fatal race condition: if multiple agent threads dispatch requests concurrently, or if an attacker extracts the session key directly, the on-chain account executes whatever transactions it receives, completely blind to the off-chain database limits.
4. Pure On-Chain Validation (Contract-Only Limits): The smart contract checks limits during ERC-4337 validateUserOp. While cryptographically secure, invalid or over-budget operations that fail on-chain still consume network gas, and debugging deep revert traces inside bundler validation frames creates severe operational friction.

The engineering solution implemented in Agent Wallet Guard is a Dual-Checkpoint Architecture, decoupling fast, zero-gas control plane reservations from immutable, deterministic on-chain execution guarantees.

2. System Architecture: The Dual-Checkpoint Pipeline

The system splits authority across two distinct security perimeters:

+----------------------------------------------------------------------------------------------------+
|                                    CONTROL PLANE (OFF-CHAIN API)                                    |
|                                                                                                    |
|  [ Autonomous Agent ]                                                                              |
|           |                                                                                        |
|           v (HTTP POST /v1/intents/evaluate)                                                       |
|  +----------------------------------------------------------------------------------------------+  |
|  | Fastify API Gateway                                                                          |  |
|  |   1. Policy Binding Check (Active, Correct Chain, Target & Selector Match)                   |  |
|  |   2. BigInt Value Parsing (Raw atomic units, e.g. 100,000,000 for 100 USDC)                 |  |
|  |   3. PostgreSQL Transaction:                                                                 |  |
|  |        INSERT spending_counters ... ON CONFLICT DO NOTHING                                   |  |
|  |        SELECT spent_raw, limit_raw FROM spending_counters ... FOR UPDATE                     |  |
|  |        Assert (spent + amount <= limit)                                                      |  |
|  |        UPDATE spending_counters SET spent_raw = spent_raw + amount                           |  |
|  |   4. Read-Only RPC eth_call Simulation (latest state)                                        |  |
|  +----------------------------------------------------------------------------------------------+  |
|           |                                                                                        |
|           | Decision: ALLOW (with TTL = 15 minutes)                                                |
|           v                                                                                        |
|  [ Sign UserOperation with Session Key ]                                                           |
+----------------------------------------------------------------------------------------------------+
                                            |
                                            | Bundler Broadcast (eth_sendUserOperation)
                                            v
+----------------------------------------------------------------------------------------------------+
|                                  DATA PLANE (ON-CHAIN ERC-4337)                                     |
|                                                                                                    |
|  [ ERC-4337 EntryPoint v0.7 ]                                                                      |
|           |                                                                                        |
|           v userOp.callData                                                                        |
|  +----------------------------------------------------------------------------------------------+  |
|  | Smart Account (AgentGuardAccount)                                                            |  |
|  |   Delegate execution to Guard Module                                                         |  |
|  +----------------------------------------------------------------------------------------------+  |
|           |                                                                                        |
|           v executeValidatedUserOp()                                                               |  |
|  +----------------------------------------------------------------------------------------------+  |
|  | AgentWalletGuard.sol                                                                         |  |
|  |   1. Verify caller is registered Smart Account & active installment epoch                    |  |
|  |   2. Decode outer call shape & strictly decode USDC Transfer calldata                        |  |
|  |   3. Recover Session Key from envelope signature -> Assert SessionStatus == Active           |  |
|  |   4. Assert target recipient is whitelisted in _allowedRecipients[policyId]                  |  |
|  |   5. Compute Day Bucket: day = uint48(block.timestamp / 1 days)                              |  |
|  |   6. Derive Storage Key: keccak256(DOMAIN, account, epoch, agentId, policyId, usdc, day)      |  |
|  |   7. Assert (_spent[key] + amount <= policy.perDayLimit && amount <= policy.perTxLimit)       |  |
|  |   8. Write: _spent[key] += amount                                                            |  |
|  |   9. Execute low-level transfer via smart account                                            |  |
|  |  10. Emit AgentPaymentExecuted(agentId, intentHash, recipient, amount)                        |  |
|  +----------------------------------------------------------------------------------------------+  |
+----------------------------------------------------------------------------------------------------+

This dual-layer structure guarantees two critical operational invariants:

• Zero-Gas Denial: If an agent hallucinates, runs out of budget, or attempts to call an unauthorized address, the API rejects the intent in less than 20 milliseconds without broadcasting a transaction. Zero gas is wasted.
• Trustless Containment: If the off-chain API is breached, compromised, or crashes, the on-chain smart contract independently rejects any transaction exceeding the daily limit, calling unapproved selectors, or using a revoked session key.

3. Off-Chain Control Plane: Atomic Reservations and Raw Units

In our earlier review of spending limit enforcement (Where to Enforce Spending Limits for AI Agents), we identified that storing token amounts as floating-point decimals (0.50 or 12.3456) in application memory is a primary vector for silent truncation errors.

In AgentWalletGuard_API, the PostgreSQL schema strictly enforces atomic-unit storage and distinct reservation lifecycles.

Durable UserOperation Reservations

From AI-Web3/AgentWalletGuard_API/migrations/0011_erc4337_operations.sql:L1-L20:

-- Durable ERC-4337 prepare reservations. The EntryPoint nonce is authoritative;
-- these rows only prevent this service from issuing two valid approvals for it.
CREATE TABLE IF NOT EXISTS user_operation_reservations (
    id TEXT PRIMARY KEY,
    organization_id TEXT NOT NULL REFERENCES organizations(id) ON DELETE CASCADE,
    wallet_id TEXT NOT NULL REFERENCES wallets(id) ON DELETE RESTRICT,
    account_address TEXT NOT NULL CHECK (account_address ~ '^0x[0-9a-f]{40}$'),
    user_op_nonce NUMERIC(78, 0) NOT NULL,
    intent_id TEXT NOT NULL,
    approval_nonce NUMERIC(78, 0) NOT NULL,
    status TEXT NOT NULL CHECK (status IN ('prepared','submitted','confirmed','failed','expired','invalidated')),
    expires_at TIMESTAMPTZ NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT user_operation_reservations_account_nonce_key UNIQUE (account_address, user_op_nonce),
    CONSTRAINT user_operation_reservations_approval_nonce_key UNIQUE (account_address, approval_nonce)
);

CREATE INDEX IF NOT EXISTS user_operation_reservations_expiry_idx
    ON user_operation_reservations (expires_at) WHERE status = 'prepared';

Notice the database constraint: CONSTRAINT user_operation_reservations_account_nonce_key UNIQUE (account_address, user_op_nonce). The control plane guarantees that it can never emit two concurrent valid approval signatures for the same on-chain sequence index.

Elimination of Concurrent Overdrafts: SELECT ... FOR UPDATE

When an evaluation request hits the API, the budget counter must not be updated via optimistic concurrency. Under high-frequency agent tool calls, optimistic locks cause massive rollback spikes.

Instead, AgentWalletGuard_API implements a deterministic two-statement pessimistic lock inside src/repositories/intents.ts:L562-L718:

// 1) Lock-or-create the counter row. `SELECT ... FOR UPDATE` blocks any
//    concurrent reservation for the same `(org, agent, day)` until the
//    caller's transaction commits / aborts.
const counterId = generateId();
const upsertResult = await exec.query<{
  id: string;
  spent_raw: string;
  limit_raw: string | null;
}>(
  `INSERT INTO spending_counters
     (id, organization_id, agent_id, window_start, window_end, base_asset,
      spent_token, spent_raw, spent_amount, spent_decimals, spent_symbol,
      limit_token, limit_raw, limit_amount, limit_decimals, limit_symbol,
      updated_at)
   VALUES ($1, $2, $3, $4, $5, $6,
           $7, '0', '0', $8, $9,
           $7, $10::numeric(78,0)::text, $10, $8, $9,
           now())
   ON CONFLICT (organization_id, agent_id, window_start) DO NOTHING
   RETURNING id, spent_raw, limit_raw`,
  [
    counterId,
    ctx.organizationId,
    ctx.agentId,
    windowStart.toISOString(),
    windowEnd.toISOString(),
    ctx.baseAsset,
    ctx.limitToken,
    ctx.limitDecimals,
    ctx.limitSymbol,
    ctx.limitRaw,
  ],
);

// Fetch the row FOR UPDATE to hold an exclusive row lock
const lock = await exec.query<{
  id: string;
  spent_raw: string;
  limit_raw: string | null;
}>(
  `SELECT id, spent_raw::text AS spent_raw, limit_raw::text AS limit_raw
     FROM spending_counters
    WHERE organization_id = $1 AND agent_id = $2 AND window_start = $3
    FOR UPDATE`,
  [ctx.organizationId, ctx.agentId, windowStart.toISOString()],
);

Once the row lock is acquired:

1. spent_raw and limit_raw are parsed using native JavaScript BigInt.
2. The comparison BigInt(spentRaw) + BigInt(ctx.amountRaw) <= BigInt(limitRaw) is evaluated.
3. If valid, spent_raw is atomically incremented, and the transaction commits, releasing the lock.
4. Any competing thread attempting to reserve budget for that agent is blocked at SELECT ... FOR UPDATE until the first transaction finishes, ensuring serialization without race conditions.

Strict UTC Window Boundaries

Many software systems suffer budget leakage at midnight because the server evaluates dates in local system time (e.g., UTC-5 or UTC+8). If the contract evaluates dates in UTC, an agent can double its daily allocation during the offset gap.

AgentWalletGuard_API aligns all daily boundaries to UTC midnight (src/repositories/intents.ts:L239-L251):

function startOfUtcDay(now: Date): Date {
  const d = new Date(now);
  d.setUTCHours(0, 0, 0, 0);
  return d;
}

function endOfUtcDay(windowStart: Date): Date {
  const end = new Date(windowStart);
  end.setUTCDate(end.getUTCDate() + 1);
  return end;
}

This matches the on-chain formula uint48(block.timestamp / 1 days) down to the exact second.

4. On-Chain Execution Layer: AgentWalletGuard.sol Deep Dive

The contract layer cannot trust that the API ran or that the database was not compromised. It operates as an autonomous gatekeeper installed as an execution module on the ERC-4337 Smart Account.

Epoched Session Keys and Instant Revocation

Session keys must never be permanent. In AgentWalletGuard_Contracts/src/AgentWalletGuard.sol:L616-L667, session keys are tied to a specific policy and bounded by a timestamp interval:

function enableSessionKey(SessionKeyInput calldata input) external onlyAccount {
    if (input.sessionKey == address(0)) revert ZeroAddress();
    if (input.validAfter >= input.validUntil) {
        revert InvalidSessionWindow(input.validAfter, input.validUntil);
    }

    Policy storage policy = _policies[input.policyId];
    if (policy.status != PolicyStatus.Active || policy.installEpoch != _installEpoch[msg.sender]) {
        revert PolicyNotActive(input.policyId);
    }
    if (policy.agentId != input.agentId) {
        revert SessionAgentMismatch(input.agentId, policy.agentId);
    }

    SessionKey storage existing = _sessions[msg.sender][input.sessionKey];
    if (existing.installEpoch == _installEpoch[msg.sender] && existing.status != SessionStatus.None) {
        revert SessionAlreadyEnabled(msg.sender, input.sessionKey);
    }

    _sessions[msg.sender][input.sessionKey] = SessionKey({
        agentId: input.agentId,
        policyId: input.policyId,
        validAfter: input.validAfter,
        validUntil: input.validUntil,
        installEpoch: _installEpoch[msg.sender],
        status: SessionStatus.Active
    });

    emit SessionKeyEnabled(input.agentId, input.sessionKey, input.policyId, input.validAfter, input.validUntil);
}

function revokeSessionKey(address sessionKey) external onlyAccount {
    SessionKey storage session = _sessions[msg.sender][sessionKey];
    if (session.status == SessionStatus.None || session.installEpoch != _installEpoch[msg.sender]) {
        revert SessionNotFound(msg.sender, sessionKey);
    }
    if (session.status == SessionStatus.Revoked) {
        revert SessionAlreadyRevoked(msg.sender, sessionKey);
    }

    session.status = SessionStatus.Revoked;
    emit SessionKeyRevoked(session.agentId, sessionKey, msg.sender);
}

When an administrator revokes a session key, session.status = SessionStatus.Revoked is committed directly to contract storage. Any in-flight or subsequent UserOperation attempting to use that key will revert on-chain during executeValidatedUserOp.

Deterministic Storage Keying and Daily Accumulation

To avoid running costly off-chain indexing or unbounded loop lookups inside the contract, AgentWalletGuard.sol uses an O(1) hashed storage layout (src/AgentWalletGuard.sol:L1058-L1135):

/// @notice Derive deterministic storage key for (account, agentId, policyId, usdc, day)
function _budgetKey(address account, bytes32 agentId, bytes32 policyId, address usdc, uint48 day)
    internal
    view
    returns (bytes32 key)
{
    key = keccak256(abi.encode(BUDGET_KEY_DOMAIN, account, _installEpoch[account], agentId, policyId, usdc, day));
}

function _checkBudgetAt(
    address account,
    bytes32 agentId,
    bytes32 policyId,
    address usdc,
    uint256 amount,
    uint48 day
) internal view {
    Policy storage policy = _policies[policyId];

    if (policy.status != PolicyStatus.Active || policy.installEpoch != _installEpoch[account]) {
        revert PolicyNotActive(policyId);
    }

    // 1) Per-transaction limit
    if (amount > policy.perTxLimit) {
        revert PerTxLimitExceeded(amount, policy.perTxLimit);
    }

    // 2) Daily limit over current day bucket
    bytes32 key = _budgetKey(account, agentId, policyId, usdc, day);
    uint256 current = _spent[key];

    if (current > type(uint256).max - amount) {
        revert DailySpentOverflow(current, amount);
    }

    uint256 next = current + amount;
    if (next > policy.perDayLimit) {
        revert DailyLimitExceeded(next, policy.perDayLimit, uint256(day));
    }
}

Key architectural details to observe:

• Zero Cleanup Overhead: The storage key embeds day = uint48(block.timestamp / 1 days). When a new UTC day begins, day increments, mapping to an entirely empty storage slot where _spent[key] is naturally 0. There is no need for periodic cron transactions or gas-heavy array resets.
• Epoch Scoping: _installEpoch[account] is embedded in the hash. If an account uninstalls and subsequently reinstalls the module, historical spent counters are invalidated instantly, preventing stale ledger state reuse.

The Execution Gate: executeValidatedUserOp

During execution, AgentWalletGuard.sol executes a ten-stage verification sequence (src/AgentWalletGuard.sol:L893-L974):

function executeValidatedUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash) external nonReentrant {
    if (!isInstalled[msg.sender]) revert NotAccount();
    if (userOp.sender != msg.sender) revert NotAccount();

    address configuredUsdc = _accountConfig[msg.sender].usdc;
    if (configuredUsdc == address(0)) revert UsdcNotConfigured();

    // 1) Decode outer call shape
    (bool shapeOk, address target, uint256 value, bytes calldata innerCallData) =
        _decodeOuterCallShape(userOp.callData);
    if (!shapeOk) revert InvalidOuterCallShape();

    // 2) Strict payment decoding (enforces exact transfer calldata)
    PaymentDecoder.Decoded memory decoded =
        PaymentDecoder.decode(configuredUsdc, bytes32(uint256(0)), target, value, innerCallData);

    // 3) Session envelope recovery and validation
    bytes calldata sig = userOp.signature;
    (bytes32 agentId, bytes32 policyId, bytes calldata sessionSig) = _decodeSessionEnvelope(sig);
    address sessionKey;
    try this._ecdsaRecoverExternal(userOpHash, sessionSig) returns (address recovered) {
        sessionKey = recovered;
    } catch {
        revert InvalidSessionSigner();
    }
    if (sessionKey == address(0)) revert InvalidSessionSigner();
    _requireActiveSession(msg.sender, sessionKey, agentId, policyId);

    // 4) Policy active & agent binding check
    Policy storage policy = _policies[policyId];
    if (policy.status != PolicyStatus.Active || policy.installEpoch != _installEpoch[msg.sender]) {
        revert PolicyNotActive(policyId);
    }
    if (policy.agentId != agentId) revert SessionAgentMismatch(agentId, policy.agentId);

    // 5) Recipient allowlist check
    if (!_allowedRecipients[policyId][decoded.recipient]) {
        revert RecipientNotAllowed(decoded.recipient);
    }

    // 6) Intent hash verification
    bytes32 intentHash = keccak256(
        abi.encode(msg.sender, agentId, policyId, decoded.recipient, decoded.amount, userOp.nonce, decoded.calldataHash)
    );

    // 7) Threshold escalation (Human-In-The-Loop check)
    if (decoded.amount > policy.approvalThreshold) {
        _enforceApproval(sig, policyId, intentHash, decoded.amount, policy.approver, policy.approvalThreshold);
    }

    // 8) Budget enforcement and recording
    uint48 day = _dayBucket(block.timestamp);
    _checkBudgetAt(msg.sender, agentId, policyId, configuredUsdc, decoded.amount, day);
    _recordSpentAt(msg.sender, agentId, policyId, configuredUsdc, decoded.amount, day);

    // 9) Execute transfer via Smart Account executor hook
    _executeUsdcTransfer(configuredUsdc, innerCallData);

    // 10) Emit immutable audit event
    emit AgentPaymentExecuted(agentId, intentHash, policyId, decoded.recipient, decoded.amount);
}

Notice Step 7: Threshold Escalation. When decoded.amount > policy.approvalThreshold, the contract enforces that sig contains not only the session key signature, but also an authorized approvalSig produced by a designated human or governance key. Low-value transactions ($< 0.50 USDC) proceed automatically; high-value purchases require cryptographic co-signing.

5. Handling Frontend & Mempool Race Conditions: The Generation Guard

Even with an airtight API and smart contract, asynchronous race conditions can plague client-side agent management interfaces. In Cancel Stale Wallet Prompts with Async Generation Checks, we explored the problem of user prompts remaining active after wallet context changes.

In AgentWalletGuard_ Frontend/src/hooks/useOwnerAuthorization.ts:L100-L115, this is resolved using an explicit Generation Guard:

const [operation, setOperation] = useState<OwnerReview | null>(null);
const [phase, setPhase] = useState<OwnerPhase>("idle");
const busy = useRef(false),
  generation = useRef(0);

useEffect(() => {
  const scope = generation;
  scope.current++;
  return () => {
    scope.current++;
  };
}, [agentId]);

Whenever an operator changes the selected agent, modifies a policy, or unmounts the review modal, generation.current increments. In the transaction confirmation workflow (src/hooks/useOwnerAuthorization.ts:L245-L337), the generation index is evaluated across every asynchronous boundary:

const gen = generation.current;

// 1. Preflight checks
const [addresses, chainId, next] = await Promise.all([
  wallet.getAddresses(),
  wallet.getChainId(),
  service.context(agentId),
]);
if (gen !== generation.current) return; // Stale execution dropped!

// 2. Local simulation
await publicClient.call({
  account: getAddress(op.owner),
  to: getAddress(next.account!),
  data: op.data,
  value: 0n,
});
if (gen !== generation.current) return; // Dropped if user switched tabs or changed accounts!

// 3. Persist intent to localStorage BEFORE prompting wallet extension
localStorage.setItem(
  authorizationRecoveryKey(agentId),
  JSON.stringify(createAuthorizationRecovery(op, null)),
);

// 4. Prompt wallet extension
const txHash = await wallet.sendTransaction({ ... });

This ensures that:

• A user cannot sign an operation prepared for Agent A while viewing Agent B.
• If the browser tab crashes after the user signs in MetaMask but before the API receives the receipt, the recovery entry in localStorage allows the UI to read the on-chain receipt on reload and complete state synchronization without double-submitting.

6. Architectural Trade-off Matrix

When evaluating defense-in-depth strategies for autonomous Web3 software, engineering teams must evaluate tradeoffs between latency, gas expenditure, and security invariants:

7. Concrete Verification: Running the Local Smoke Suite

The architecture described here is not a theoretical whitepaper; it is verified inside the local test harness of Agent Wallet Guard.

As documented in the repository runbook (AgentWalletGuard_ Frontend/docs/LOCAL_PAYMENT_LOOP_RUNBOOK.md), the full stack operates across a local Anvil chain (Chain ID 1337), an Alto Bundler (ERC-4337 EntryPoint v0.7), a Fastify API gateway, and a PostgreSQL database.

Running the End-to-End Verification Pipeline

From the frontend root directory:

# 1. Start isolated local infrastructure (PostgreSQL, Redis, Anvil, Alto Bundler)
npm run local:stack -- up

# 2. Run system doctor to verify network binds, contract deployments, and RPC connectivity
npm run local:stack -- doctor

# 3. Execute the full payment and failure smoke test suite
npm run local:stack -- smoke

The smoke suite deterministically executes the following verification stages:

1. Valid Execution: Agent submits a 1.00 USDC intent with valid session key. API status = ALLOW, UserOperation bundles, contract executes, AgentPaymentExecuted emitted.
2. Selector Rejection: Agent attempts to call transferFrom or approve instead of standard transfer. API status = DENY (SELECTOR_NOT_ALLOWED), zero gas consumed.
3. Daily Budget Rejection: Agent submits an intent that pushes total spend from 900,000 raw units to 1,400,000 raw units against a 1,000,000 limit. API returns DENY with code DAILY_LIMIT_EXCEEDED (test/intents.test.ts:L419-L470).
4. On-Chain Revocation Rejection: Operator clicks revoke on session key. A raw UserOperation signed with the revoked key is directly injected into the bundler (bypassing the API). The transaction reverts on-chain with SessionAlreadyRevoked or InvalidSessionSigner, proving contract containment.

8. Integration & Commercial Next Steps

Integrating autonomous agents into enterprise software requires moving beyond reckless prototype hacks. Unchecked EOA keys and brittle webhooks will inevitably result in security incidents and financial loss.

By deploying an ERC-4337 dual-checkpoint architecture, engineering teams achieve the optimal balance: millisecond response times and zero gas wastage for routine operations, backed by immutable on-chain smart contract guardrails that guarantee budget limits cannot be breached.

Recommended Implementation Roadmap:

1. Audit Existing Agent Spending Boundaries: Review your current agent workflows and identify whether private keys are exposed directly to LLM execution contexts.
2. Review the Foundation Codebase: Review our companion engineering guides on AI Agent Wallet Access Before Your First Integration and Where to Enforce Spending Limits for AI Agents.
3. Explore the Working Product: Review the screen captures, verified workflows, and architecture documentation on the Agent Wallet Guard Product Page or the 中文版产品主页.
4. Schedule an Architecture Review: If your team is preparing to launch autonomous agent payments or requires a customized enterprise deployment (supporting custom token assets, KMS hardware security modules, or multi-tenant agent fleets), book an architecture walkthrough or request an implementation proposal.