ZeroDev Technical Requirements

A comprehensive specification of the infrastructure, API, and SDK capabilities required to support high-velocity development for our Smart Account application.

1. Core Account Infrastructure

Deterministic Account Factory

Core Capability

Reliable generation and resolution of Smart Account addresses before deployment. We require a consistent address derivation scheme based on a unique owner identifier (EOA or Passkey) and an index/salt.

Function: predictAccountAddress(owner, salt)

Requirement: Must return the same address across different sessions/devices.

Batch Transaction Support

Core Capability

Native support for "atomic batch" operations. The SDK must allow bundling multiple calls (e.g., approve + swap) into a single UserOperation without manual calldata encoding.

Input: Array of `{ to, value, data }` objects.

Guarantee: All-or-nothing execution on-chain.

2. Gas Abstraction & Paymasters

Custom ERC20 Gas Payment

Critical Developer Need

We require a turnkey solution to allow users to pay gas fees using a specific stablecoin (e.g., BRLA). This must be configurable via a dashboard or API without requiring us to deploy and maintain custom Oracle/Paymaster smart contracts.

Automatic token price conversion/oracle management.
Support for whitelisting specific ERC20 tokens (BRLA, USDC).
Fallback mechanisms if the primary token Paymaster fails.

3. Data Indexing & State Retrieval

This section represents the highest friction point in development. Replacing "Direct RPC Calls" with "Indexed Data APIs" drastically improves frontend performance and reduces backend complexity.

Unified Portfolio API

Critical Productivity Accelerator

An API to instantly fetch the consolidated asset state of a Smart Account. Development is significantly slowed if we must manually query individual token contracts via RPC.

Endpoint: GET /accounts/{address}/portfolio

Returns: List of held assets (Native + ERC20).

Include: Balances, Token Metadata (Symbol, Decimals), Prices (Fiat value).

Transaction History Feed

Critical User Experience

Users require a human-readable feed of their past activity. We need an indexed history API that decodes UserOperations into understandable events.

Must differentiate between Incoming (Deposits) and Outgoing (Withdrawals/Calls).
Resolution of timestamps, gas used, and status (Success/Reverted).
Correction for "Internal Transactions" (e.g., receiving tokens via a transfer inside another tx).

3.5. BRLA Token Indexing & Support

BRLA is our application's native stablecoin. Complete indexing and gas payment support for this token is mission-critical.

BRLA Token Technical Specification

Core Asset

BRLA is a Brazilian Real-pegged stablecoin deployed on Base Chain (Chain ID: 8453). It serves as the primary medium of exchange within our application ecosystem.

Token Name: BRLA

Symbol: BRLA

Decimals: 18

Contract (Base): 0xfCB34c47f850f452C15EA1B84d51231C38A61783

Standard: ERC20 + ERC20Permit (EIP-2612)

Permit Support: Yes (Gasless approvals via signature)

BRLA Balance Indexing Requirement

Critical Indexing Need

The Portfolio API (Section 3.1) must natively recognize and index BRLA balances. We cannot afford to treat BRLA as a "generic ERC20" that requires manual contract address configuration.

Automatic detection of BRLA holdings for any Smart Account on Base.
Real-time balance updates when BRLA is transferred in/out.
Historical balance snapshots for compliance/auditing.

BRLA Transfer Event Monitoring

Critical Event Stream

We require dedicated webhook support for BRLA Transfer events. This is distinct from the generic "Asset Received" webhook (Section 4.1) and should provide BRLA-specific metadata.

Event Signature: Transfer(address indexed from, address indexed to, uint256 value)

Filter: Contract = 0xfCB34c47f850f452C15EA1B84d51231C38A61783

Trigger Condition: to parameter matches a registered Smart Account.

BRLA as Gas Payment Token

Critical UX Feature

Users must be able to pay transaction fees using their BRLA balance instead of holding native ETH. This requires a properly configured ERC20 Paymaster with BRLA whitelisted.

Paymaster Configuration: ZeroDev should provide a hosted or easily deployable Paymaster that accepts BRLA.
Oracle Integration: Real-time BRLA/ETH price feed to calculate gas costs in BRLA terms.
Fallback Mechanism: If BRLA balance is insufficient, gracefully fall back to sponsored gas or notify the user.
Permit Integration: Leverage ERC20Permit to avoid requiring a separate approval transaction before gas payment.

Expected Flow: User signs UserOp → Paymaster deducts BRLA → Bundler submits tx with ETH.

Requirement: Zero manual smart contract deployment by our team.

4. Real-Time Event Infrastructure

Universal Incoming Asset Webhook

Critical Logic Trigger

Our application logic relies on detecting when a user tops up their wallet. We require a reliable webhook system that notifies our backend whenever a Smart Account receives value.

Event: ASSET_RECEIVED

Trigger: Any transfer of Native or ERC20 tokens TO the account.

Payload: To, From, Asset Address, Amount, TxHash.

Operation Status Webhooks

Core Capability

Proactive notification of UserOperation finality. We cannot rely on the client keeping the browser window open to poll for transaction receipts.

Webhooks for USER_OP_SUCCESS and USER_OP_REVERTED.
Delivery guarantees (retries on 500 errors).