OpenZeppelin Relayer primary sources

Collected: 2026-05-15 UTC

1) OpenZeppelin Relayer docs

Key points captured:

OpenZeppelin Relayer is presented as a backend service for relaying transactions across EVM and non-EVM networks.
The docs emphasize multi-chain support, transaction relaying, transaction signing, fee estimation, nonce management, transaction-status monitoring, metrics/observability, Docker deployment, and plugins.
Supported network families include EVM, Solana, and Stellar.
The docs explicitly say the service is not meant to be directly exposed to the public internet and should sit behind the operator’s own secure backend.

Key points captured:

The relayer supports both file-based configuration (config.json, .env) and API-based runtime CRUD for relayers, signers, and notifications.
Storage, rate limiting, distributed mode, queue backends, Redis settings, encryption keys, provider retry/failover thresholds, allowed RPC hosts, and private-IP blocking are all explicit operator-controlled parameters.
This makes operational policy part of the relayer’s exposed control surface rather than a hidden hosted-service default.

Key points captured:

The relayer supports local keystore, HashiCorp Vault, HashiCorp Vault Transit, Turnkey, Google Cloud KMS, AWS KMS, and Coinbase Developer Platform signers.
Signer compatibility varies by network family, making key-management choice and chain support explicit instead of implicit.
The docs recommend restrictive permissions on local keystore files and encourage HSM-backed or managed signers in production.

Key points captured:

Plugins are TypeScript handlers that run inside the relayer server and can include arbitrary operator-defined logic.
Plugins get access to the relayer API, request params, HTTP headers, routing info, and a persistent key-value store.
Plugins can expose multiple routes, call relayers directly, persist state, and optionally emit logs/traces or raw responses.
This shows the relayer is not just a signing/broadcast tool, but a programmable middleware layer.

Key points captured:

OpenZeppelin says Defender is in maintenance mode and recommends migrating monitoring and relaying workflows to open-source tools.
The migration guide says Defender shuts down on 2026-07-01 and explains how to export relayer configs and recreate them in OpenZeppelin Relayer.
The guide highlights an important signer-control fact: Defender Relayer keys cannot be exported from AWS KMS, so migration requires new relayers and new addresses.
This makes custody portability and signer backend choice a meaningful comparison point.

Key points captured:

The README reiterates multi-chain relaying, signer support, fee estimation, nonce handling, status monitoring, plugins, and metrics.
The repo’s architecture diagram separates API/controllers, middleware/plugins, domain logic/policies, repositories/jobs, signer/provider services, and external systems like Redis, Vault, blockchain networks, and notification services.
The repo structure reinforces that the relayer is an operator-run backend platform rather than a single-purpose SDK.

Key points captured:

Defender’s landing page says new sign-ups were disabled on 2025-06-30 and that final shutdown is 2026-07-01.
The page frames Defender as the older integrated operational security platform whose relaying and monitoring surfaces are being replaced by open-source modules.
This helps place OpenZeppelin Relayer in the broader product transition from hosted control plane to self-hosted operator stack.