alchemy-reference-architecture
Alchemy Production Reference Architecture
Overview
Design a production Alchemy architecture with capability-specific adapters, explicit trust boundaries, partial-state semantics, and reversible operations. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.
Prerequisites
- Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
- Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
- Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.
Current Contract
Current architecture separates EVM RPC through viem, Data APIs through typed HTTP adapters, Wallet APIs v5 through a transaction-policy boundary, Notify intake through authenticated idempotent queues, and Admin usage through restricted operations tooling. No shared archived SDK client or credential should collapse these contracts.
Authentication
Model browser, edge, API, worker, webhook, Admin, and signer identities separately. Application keys may serve permitted reads; Admin access keys, Notify tokens, webhook signing keys, and wallet signing authority remain isolated by runtime, owner, and policy.