# Private mempool routing for DALP transactions Source: https://docs.settlemint.com/docs/architecture/security/private-mempool-routing How to route DALP transaction submission through a private or encrypted mempool service by replacing the public RPC endpoint, what the service protects against, and what remains an operator responsibility. A private or encrypted mempool service replaces the public JSON-RPC submission path with a relay that hides pending transactions from the public mempool until inclusion. DALP signs and submits configured EVM transactions through the JSON-RPC endpoint named in chain configuration, so the routing decision is a configuration choice, not a contract change. This page covers the two integration shapes the platform supports, the chain-configuration values to set, what the route protects, and what it does not. Use this page when an asset programme on a public EVM network needs to reduce pre-inclusion visibility of mints, redemptions, treasury writes, role changes, or other high-signal operations. The chosen response is to route DALP transactions through a relay rather than move to a permissioned network. ## Prerequisites [#prerequisites] Confirm the following before routing transactions through a private mempool service: * A signed agreement with the relay or service operator that names supported chains, supported JSON-RPC methods, transaction privacy guarantees, fallback behaviour, and dispute resolution. * A configured DALP environment for the target chain with the deployed DALP contract addresses recorded in the network configuration. See [supported networks](/docs/architecture/integrations/supported-networks). * A decision from security, compliance, and legal that the asset programme accepts the trust assumptions of the chosen relay operator and the broader builder set the relay can reach. * A reconciliation path that uses DALP transaction tracking against the public chain after inclusion. See [transaction tracking](/docs/developer-guides/operations/transaction-tracking). ## What a private mempool service does [#what-a-private-mempool-service-does] A private mempool service accepts a signed transaction, holds it outside the public peer-to-peer mempool, and submits it to block builders, proposers, or sequencers that the service has a relationship with. The service hides transaction calldata, signer, recipient, and amount from the public mempool until a builder includes the transaction in a block. The relay model varies by service: | Relay model | How transactions reach a block | Typical chain support | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Direct builder submission | The relay forwards the signed transaction to one or more block builders that include the bundle in a candidate block. The proposer accepts the block as part of normal block flow. | Ethereum mainnet and chains with MEV-Boost-style builder markets. | | Sequencer-private submit | The relay sends the transaction to the network sequencer through a private endpoint. The sequencer includes the transaction without first publishing it to a public mempool. | Rollups whose sequencer exposes a private submission endpoint. | | Encrypted mempool | The relay accepts an encrypted transaction, releases the plaintext only after ordering is committed, and submits the decrypted transaction to the builder or sequencer for inclusion. | Networks with encrypted mempool protocols and supporting client integrations. | Across all three models, finality, balance changes, emitted events, and contract state remain public after inclusion. The relay changes who can see the transaction before it lands, not what becomes visible once it lands. ## Two integration shapes [#two-integration-shapes] Private mempool services expose their relay through one of two JSON-RPC surface shapes. The integration with DALP depends on which shape the service uses. ### Shape one: drop-in JSON-RPC endpoint [#shape-one-drop-in-json-rpc-endpoint] The service exposes a full JSON-RPC interface and accepts read methods (`eth_call`, `eth_getLogs`, `eth_blockNumber`) as well as write methods (`eth_sendRawTransaction`). The endpoint can replace a public RPC URL for the whole chain. | DALP setting | Value | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `rpc.url` | The relay's JSON-RPC endpoint URL. | | `rpc.urls` | Use only relay endpoints that preserve the same private-write guarantee. Do not add a public broadcast fallback when every write must stay private. | | `wsUrl` | Set when the relay exposes a WebSocket subscription endpoint. | | `supportsFinalizedTag` | Match the underlying chain's behaviour. The relay typically inherits the chain's finalized tag. | | `finalityConfirmations` | Match the underlying chain's confirmation policy. | | RPC limits and batching | Apply the relay's documented `getLogs` and concurrency limits. | Drop-in endpoints are the simplest to wire because DALP services do not need to distinguish reads from writes. If the deployment requires every write to stay private, treat a relay outage as a fail-closed condition. A fallback transport can retry the same write on another configured endpoint, so any fallback endpoint must provide the same private submission guarantee. Use a Chain Gateway write-path split when reads need a public RPC but writes must never broadcast publicly. The relay terms of service still apply, including rate limits, retention policy, and any logging the relay performs on inbound transactions. ### Shape two: send-raw-only relay [#shape-two-send-raw-only-relay] The service accepts only `eth_sendRawTransaction` (and sometimes `eth_sendBundle` or a vendor-specific method) on its private endpoint. Read methods, transaction-status polling, log fetching, and block-tracking calls must still resolve through a regular RPC. Use the [Chain Gateway](/docs/architecture/components/infrastructure/chain-gateway) to split the traffic: configure one upstream that handles reads and one upstream that handles the private write path. Restrict the private upstream to the methods the relay accepts. ```yaml erpc: config: projects: - id: dalp networks: - architecture: evm upstreams: - id: read-rpc endpoint: https://reads.example.com evm: {} allowMethods: - "*" ignoreMethods: - "eth_sendRawTransaction" autoIgnoreUnsupportedMethods: false - id: private-mempool-write endpoint: https://private-relay.example.com evm: {} allowMethods: - "eth_sendRawTransaction" autoIgnoreUnsupportedMethods: false ``` DALP services keep calling the same internal gateway URL. The gateway routes `eth_sendRawTransaction` to the private relay and every other method to the read upstream. Keep `autoIgnoreUnsupportedMethods: false` on both upstreams so a transient `unsupported` response does not silently re-route a private write to the public read path. ## Decision matrix [#decision-matrix] Use this matrix to compare the two shapes against the operational footprint they require. | Question | Drop-in JSON-RPC endpoint | Send-raw-only relay | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | | Where is the relay configured? | Directly in the DALP network configuration as `rpc.url` or in `rpc.urls`. | As a Chain Gateway upstream scoped to `eth_sendRawTransaction`. A separate read upstream serves every other method. | | Does DALP code change? | No. DALP uses the configured RPC URL. | No. DALP keeps calling the gateway URL. | | Are reads private? | Read traffic flows through the relay subject to its retention and access policy. | Reads continue to use a regular RPC and remain as private as that RPC. | | What happens if the relay drops a transaction? | The private write fails closed unless another private relay endpoint is configured. DALP transaction tracking reports it as pending or stuck. | Same. DALP transaction tracking reports it as pending or stuck. | | Can a fallback resubmit publicly? | Avoid public broadcast fallbacks when every write must stay private. Use only private-equivalent fallback endpoints, or leave the write stuck for operator action. | Not when the read upstream blocks `eth_sendRawTransaction` and the private upstream is the only write route. | | What happens to subscriptions? | Configure `wsUrl` against the relay when supported; otherwise DALP falls back to HTTP polling. | The read upstream serves subscriptions when it exposes a WebSocket endpoint. | ## Reference providers [#reference-providers] Public services that operate one of the relay models above and accept signed transactions from any client. Confirm current chain coverage, supported methods, retention policy, service-level agreement, and contract terms with the provider before procurement. Free retail endpoints exist for most of these services; production deployments that need rate guarantees or audit support usually require a separate agreement with the operator. | Service | Relay model | Integration shape | Primary chain coverage | | -------------------------------------------------------------------------------------- | ------------------------- | -------------------------------------- | ----------------------------------- | | [Flashbots Protect](https://docs.flashbots.net/flashbots-protect/overview) | Direct builder submission | Drop-in JSON-RPC | Ethereum mainnet, Sepolia, Holesky. | | [MEV Blocker](https://mevblocker.io/) | Direct builder submission | Drop-in JSON-RPC | Ethereum mainnet. | | [bloXroute Protect](https://docs.bloxroute.com/core-solutions/rpc-service/protect-rpc) | Direct builder submission | Drop-in JSON-RPC plus `eth_sendBundle` | Ethereum mainnet, BNB Smart Chain. | Sequencer-private submission on a rollup requires the chain operator's private endpoint. Contact the operator (for example Arbitrum or Optimism) for the URL, supported methods, and contract terms. Encrypted-mempool networks (for example Shutter on Gnosis Chain) provide the capability at the network and validator level rather than as a separate RPC service, so the decision is to deploy on that network rather than procure a relay. ## What the route protects [#what-the-route-protects] A private mempool route reduces specific visibility surfaces. Map each protection to the threat it addresses. | Protection | Threat addressed | | ------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Pending transaction hidden from peers | Public mempool snooping, generalized front-running of pending intent, sandwich attacks on swaps. | | Calldata hidden until inclusion | Adversaries inferring mint, burn, redemption, freeze, or role-change intent before the operation lands. | | Bundle ordering through the relay | Reorderings by independent searchers competing for the same block space against your transaction. | | Optional bundle revert protection | A failed simulation discarding the bundle before the relay submits it, when the relay supports this flag. | ## What the route does not change [#what-the-route-does-not-change] A private mempool route does not change anything after inclusion and does not remove every observer. | Item | Why the route does not change it | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Transaction inputs after inclusion | Calldata, signer, recipient, and amount are public once the block is final. | | Emitted events | Token, identity, registry, and compliance events follow the configured contracts and are visible on the public chain. | | Contract state | Balances, registry entries, claims, and module state remain readable through any public RPC after inclusion. | | Validator and builder visibility | The relay's builder set, proposer set, or sequencer can see plaintext when they receive the transaction. Trust depends on the relay terms. | | Finality behaviour | Finality is set by the underlying chain. The relay does not change confirmation depth or reorg risk. | | Cross-chain or off-chain disclosure | KYC, KYB, AML, sanctions evidence, custody attestations, and reserve reports remain owned by the operator's off-chain controls. | | Regulatory reporting | Transaction reporting, market-abuse monitoring, and disclosure obligations remain owned by the asset programme. | | Generic MEV immunity | Routing reduces some MEV categories but does not produce a generic "MEV-proof" deployment. Assess each operation against its threat model. | ## Reconciliation and transaction tracking [#reconciliation-and-transaction-tracking] DALP transaction tracking polls the configured chain for receipts and reconciles submitted writes against final chain state. Private mempool routing does not change that loop, but it does change two operational behaviours. | Behaviour | Effect of private mempool routing | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Receipt source | Receipts come from the underlying chain. Configure the read upstream against a regular RPC for that chain so DALP can poll receipts even when the write path is private. | | Replacement transactions | A relay may drop or deprioritize replacement transactions that change nonce, gas policy, or signer. Document the relay's replacement and cancellation behaviour before relying on retries. | | Stuck transactions | A transaction that never reaches a builder remains pending without entering a public mempool. Decide whether to escalate, resubmit through the same relay, or escalate to a public broadcast. | | Audit evidence | Record the relay identity, endpoint, request ID, and submission timestamp alongside the eventual block, transaction hash, and reconciliation outcome. | ## Operator checklist [#operator-checklist] Run this checklist before a regulated asset programme starts routing transactions through a private mempool service. 1. Name the chain, the relay, the supported methods, and the relay's documented behaviour for stuck and dropped transactions. 2. Decide whether the relay replaces the public RPC entirely or only the write path. Configure DALP accordingly. 3. Decide whether any operation may fall back to a public broadcast. For private-write requirements, configure fail-closed behaviour: keep public RPC endpoints out of `rpc.urls` for the write path, or use Chain Gateway so only the private upstream can handle `eth_sendRawTransaction`. 4. Confirm that DALP transaction tracking can poll receipts against a public or operator-controlled RPC for the same chain. 5. Confirm that the relay's logging, retention, and access policy is acceptable to compliance and that the trust boundary is documented. 6. Confirm that the relay's terms cover the operations the asset programme cares about, including mints, redemptions, treasury writes, freezes, and role changes. 7. Record the relay identity, endpoint, and policy version in launch evidence. Re-confirm when the endpoint, supported methods, contract terms, or asset scope shifts. ## Ownership matrix [#ownership-matrix] | Area | Operator owns | DALP provides | Relay operator owns | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Relay selection and contract terms | Choose the relay, sign the agreement, and renew it on schedule. | Documentation that names DALP's transaction submission model and the configuration values that route writes through a relay. | Service definition, supported methods, fallback behaviour, retention, and dispute handling. | | Network configuration | Set `rpc.url`, `rpc.urls`, `wsUrl`, finality settings, and RPC limits for the chosen relay. | DALP configuration schema for built-in viem chains and custom EVM chains. | Endpoint availability, rate limits, and any vendor-specific methods. | | Chain Gateway upstreams | Define the per-upstream `allowMethods` and `autoIgnoreUnsupportedMethods` policy for the relay and read paths. | Chain Gateway with eRPC routing, retries, hedging, and caching across upstreams. | The private endpoint's response semantics and method support. | | Reconciliation | Reconcile DALP transaction tracking against the public chain receipt and the operator's treasury or reserve record. | Transaction tracking, receipt polling, replacement support, and operator-facing status surfaces. | Submission acknowledgement, bundle status, and any inclusion or drop signal the relay exposes. | | Audit and disclosure | Record the relay identity, policy, and evidence trail. Decide what to disclose to regulators or counterparties. | Audit-log emission for DALP submission, signing, and tracking events. | Any audit or reporting that depends on the relay's logs. | ## Related primitives [#related-primitives] * [Public chain privacy on EVM networks](/docs/architecture/security/public-chain-privacy) for the decision frame and the threat model that justifies a private route. * [Supported networks](/docs/architecture/integrations/supported-networks) for the chain configuration that owns `rpc.url`, `rpc.urls`, and finality settings. * [Chain Gateway](/docs/architecture/components/infrastructure/chain-gateway) for the eRPC upstream model that splits private write traffic from public read traffic. * [Transaction tracking](/docs/developer-guides/operations/transaction-tracking) for the reconciliation loop that runs after submission. * [Replay, idempotency, and mint controls](/docs/architecture/security/replay-idempotency-mint-controls) for the safeguards that apply when a relay drops, delays, or returns ambiguous status for a submitted transaction.