Private mempool routing for DALP transactions

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

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.
• 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.

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:

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

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

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.

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

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 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.

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

Use this matrix to compare the two shapes against the operational footprint they require.

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.

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

A private mempool route reduces specific visibility surfaces. Map each protection to the threat it addresses.

What the route does not change

A private mempool route does not change anything after inclusion and does not remove every observer.

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.

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

Related primitives

• Public chain privacy on EVM networks for the decision frame and the threat model that justifies a private route.
• Supported networks for the chain configuration that owns rpc.url, rpc.urls, and finality settings.
• Chain Gateway for the eRPC upstream model that splits private write traffic from public read traffic.
• Transaction tracking for the reconciliation loop that runs after submission.
• Replay, idempotency, and mint controls for the safeguards that apply when a relay drops, delays, or returns ambiguous status for a submitted transaction.