Bastion

Bastion is an ERC-4337 smart account system with session key support, paired with a Go indexer that reads account activity back off-chain. Contracts are Solidity on Foundry, the indexer runs on the Go standard library, and one SvelteKit frontend serves both halves. All four contracts are deployed and verified on Sepolia, with gas sponsored by a Pimlico paymaster so the demo runs without testnet ETH.

Account abstraction moves signature validation out of the protocol and into the account itself. That makes scoped delegation possible: a temporary key that can call one function, on one contract, inside one time window. Session keys are what make smart accounts worth the added complexity, and they're usually the part that gets skipped, or demoed without revocation.

Reading the history back is a separate problem. Once accounts emit UserOperationEvent, something has to index those logs and survive reorgs without double-counting or serving partial state. Most reference implementations stop at the contract.

• Account: SmartAccount validates the owner via ECDSA, with a separate path for session keys, exposing execute and executeBatch. Accounts sit behind ERC1967 proxies deployed by a CREATE2 factory, so an address derives from (owner, salt) and is usable before deployment. initCode on the first UserOp deploys the proxy in the same transaction that validates it.
• Session keys: Scope lives in _validateSessionKey on the account. Each key binds to a target address, a 4-byte selector, and a validAfter/validUntil window. Compromising one key grants nothing on any other account that authorizes the same public key.
• Indexer: Go on net/http with no framework and no ORM. eth_getLogs polling is the authoritative range scanner and the only path that handles reorgs. An eth_subscribe feed on newHeads wakes the loop early, and if the socket drops, polling continues unchanged.
• Reorg handling: Only blocks below latest - confirmations get indexed, and each pass rewinds a configurable window before rescanning. Delete-above, insert, and cursor update commit as one Postgres transaction, so readers never see a half-applied range.
• Frontend: Svelte 5 with viem and permissionless.js. Session keypairs are generated in browser memory and never persisted. The SessionKeyAdded and SessionKeyRevoked events are the source of truth.

• Session key lifecycle runs end to end: generate, register, execute from a second tab signing locally, then revoke and watch the same call fail validation at the EntryPoint
• Killing the indexer mid-run and restarting it resumes from the persisted cursor, rewinds, and catches up without duplicating rows
• Roughly one line of Go test per line of source across decoding, RPC retry, safe-head, and database layers, with Foundry tests on all four contracts
• Documented limitations covering the absent upgrade path, lack of social recovery, selector-level-only scoping, and the session key fee surface