The system you're taking over, in one mental model: the frontend never touches a chain, one service writes, one reads, and Fireblocks holds every key. Everything else hangs off this.
The frontend never touches a chain. No MetaMask, no WalletConnect, no in-browser signing — anywhere. All on-chain execution is isolated behind the backend, and all key custody lives in Fireblocks. In Gateway, Web3 is a backend concern; the UI is orchestration and monitoring.
This is the institutional answer to Lesson 6. A regulated platform cannot have private keys in browsers or staff laptops. Fireblocks is API-accessed MPC infrastructure — keys are split into shares across hardware enclaves (TSS/MPC-CMP) and never assembled; your backend requests a signature, it never holds a key.1 So the architecture isn't a style choice — it's custody and compliance dictating the shape.
If you remember one sentence about Gateway: "The chain is a slow, async edge reached only through a backend, and the keys live in Fireblocks — never the browser."
Gateway splits chain interaction into exactly two directions — your Lesson 10 Signer-writes / Provider-reads split, promoted to whole services:
gateway-blockchain-connector. Consumes DEPLOY_QUEUE / CHAIN_ACTION_QUEUE off Azure Service Bus; executes deploys, MINT, BURN, TRANSFER, DIVIDEND, trustline ops, Solana freeze — via Fireblocks. The server-side Signer (Lesson 10), made institutional. Per-chain handlers; SHA-512 idempotency keys; writes results to transaction_out.
gateway-blockchain-listener. Subscribes to chain events (viem WS for EVM, XRPL/Stellar/Solana equivalents), decodes Transfer / AllowList changes, normalizes to a ChainEvent (TRANSFER / WHITELIST), writes DB tables, and publishes to TRANSFER_EVENT_TOPIC. The Provider + event-subscription side (Lessons 3, 5, 10), made institutional.
This separation is deliberate and powerful: one service can write, exactly one can read, and nothing else ever speaks to a chain. Auditable, securable, and the blast radius of a bug is contained to one direction.
Read it as a loop. A command goes down the write path (UI → orchestration → bus → connector → Fireblocks → chain). The result comes back up the read path (chain → listener → DB/topic → token-service confirms → recon checks). The two paths are asynchronous and decoupled — the chain's latency never blocks the UI, and confirmation is an event that arrives later. This is the on/off-chain boundary (Lesson 5) realised as message-passing.
The frontend doesn't wait for a transaction; it fires a command and watches for confirmation. Azure Service Bus between orchestration and connector buys you: decoupling (UI returns instantly), retries & durability (a queued action survives a connector restart), and back-pressure (chain congestion can't topple the API). The SHA-512 idempotency keys matter here — if a message is delivered twice, the connector must not mint twice. Idempotency is what makes "at-least-once" delivery safe for irreversible chain actions.
recon-service is the safety net that detects the resulting drift (MATCHED/UNMATCHED) — but detection isn't prevention. This is exactly the kind of inherited risk a new engineering lead should surface, prioritise, and own.
| Gateway piece | You already learned it as… |
|---|---|
| Frontend never signs; keys in Fireblocks | Custody / MPC / agent-key protection (Lessons 6, 8) |
| connector = the only writer | The server-side Signer (Lesson 10) |
| listener = the only reader | Provider + events as the sync feed (Lessons 3, 5, 10) |
| Async write/read paths over a bus | The on/off-chain boundary (Lesson 5) |
| AllowList contract for whitelisting | Permissioned transfer / identity gate (Lesson 4) |
| recon-service | Reconciliation of on- vs off-chain books (Lesson 5) |
| Solana Token-2022 freeze/thaw, ATA | Default-frozen + permissioned tokens (Lessons 7, 8) |
You are not learning Gateway from scratch — you're recognising it. The rest of this track names the parts and goes deep on the few genuinely new things (the ERC20F/ERC20MN01 standard, XRPL/Stellar trustlines, the 6.5 collapse).
From memory. Interleaves Lessons 5, 6 & 10.
Your single best source is Gateway's own docs/architecture.md (especially the 6.5 target) — read it against this lesson's frame. To ground the building blocks: Fireblocks — What is Fireblocks (the custody model) and QuickNode — Reorg & checkpoint handling (why the in-memory checkpoint is a risk).