What CryptoRail does not do

For everyone technical.

In short

CryptoRail is the layer between your business systems and EVM networks: it signs through your keys, prices and sends transactions, follows them to finality, enforces your policies and approvals, sponsors your end customers’ gas and delivers contract events. It deliberately stops there.

This page lists the edges, so an evaluation does not discover them late. Each item has one of three statuses:

• Out of scope by design: we do not do it and do not plan to, usually because doing it would weaken something else CryptoRail promises.
• On request: designed, with requirements written and the port in place, but built only when a customer needs it.
• Waiting for the audit: built and tested, but not offered for real value until an external security audit has been carried out.

flowchart LR
    subgraph IN[What CryptoRail does]
        S[Signing through your keys]
        T[Transactions to finality]
        P[Policies and approvals]
        G[Sponsored gas]
        E[Contract events]
    end
    subgraph OUT[Out of scope by design]
        K[Custody of end-customer keys]
        WAL[Wallets and end-user interfaces]
        NE[Non-EVM chains]
        C[Writing your contracts]
        F[Fiat on- and off-ramps]
        O[Orchestrating multi-step operations]
    end
    subgraph REQ[On request]
        B[Message brokers]
        M[More key managers and custodians]
        A[mTLS, OIDC, more SDKs, dashboards]
    end
    subgraph AUD[Waiting for the audit]
        H[Run for you in production]
    end

Out of scope by design

Custody of your end customers’ keys

Custody of your end customers' keys. Not supported

When CryptoRail sponsors your end customers’ gas, their accounts are owned by their own wallets. CryptoRail pays for their operations; it never holds a key that controls their account, and it never can. For your own keys the same principle holds one level up: the key stays in your HSM, your cloud KMS or your own signer, and CryptoRail asks for signatures.

Your end customers act without holding gas: CryptoRail sponsors their operations through ERC-4337 paymasters, and their keys stay in their own accounts.

Keys never enter CryptoRail: signing happens in your HSM, your cloud KMS or your own signer, and only the development signer ever touches a key.

Why: a component that holds end-customer keys becomes a custodian, with the regulation, the liability and the attack surface that come with it. Keeping keys out is what lets the security model say that a compromised CryptoRail process cannot sign anything on its own.

Wallets and end-user interfaces

Wallets and end-user interfaces. Not supported

CryptoRail talks to wallets through standards (ERC-7677 for sponsorship) and does not ship one, nor a browser extension, nor screens for your end customers. The consoles you may see in a demonstration are built over a sandbox to show the flows; they say they are a sandbox and are not a product.

Wallets ask for sponsorship through the standard ERC-7677 interface, authenticated per application and held to quotas.

Why: the end-user experience is yours, and wallets already exist; the value CryptoRail adds is behind them.

Blockchains outside the EVM family

Blockchains outside the EVM family. Not supported

Every EVM network is in scope, public or permissioned, including consortium networks without fees. The ports do not rule other families out, but no effort is spent on them.

Several networks at once, each declared in configuration, with every record carrying the network it belongs to.

Permissioned consortium networks with free gas (Hyperledger Besu with QBFT): no fee market, no gas balance to keep topped up.

Writing or auditing your smart contracts

Writing or auditing your smart contracts. Not supported

CryptoRail consumes contracts; it does not write them. You bring the ABI of any deployed contract, yours or a third party’s, and you can deploy your own compiled contracts through it under your policies and approvals. The pilot packs include a few example contracts of our own, built on OpenZeppelin Contracts, to make a pilot runnable; they are examples, not a contract development service. The smart accounts and paymasters used for sponsorship are canonical, audited, public implementations, never contracts written for CryptoRail.

Bring the ABI of any deployed contract, yours or a third party's, as JSON or in readable form, even with only the functions and events you use, and check it against the deployed code.

Deploy your own contracts from CryptoRail, on a test network or a real one, under your policies, your approvals and your signer; the confirmed transaction returns the contract's address.

Only the canonical EntryPoint and public account and paymaster contracts from audited lineages, pinned per network; no custom contract.

Two developer conveniences around contracts are on the roadmap rather than built: deploying with one command from a Hardhat or Foundry build, and a typed OpenAPI document per contract.

Deploy with one command from your Hardhat or Foundry build, the contract registered under its name in the same step. On the roadmap

A typed OpenAPI document generated for each of your contracts, so your developers call it through a typed client. On the roadmap

Fiat on-ramps and off-ramps

Fiat on-ramps and off-ramps. Not supported

CryptoRail moves tokens on chain; converting between money and tokens, and any exchange integration, belongs to your payment or exchange provider.

Orchestrating multi-step business operations

Orchestrating multi-step business operations across separate transactions, or compensating a failed step: CryptoRail groups, traces and reports them, the sequencing is your business logic. Not supported

An operation that spans several transactions (approve, then supply, then record) is grouped under your operation id, traced as one and reported step by step, but CryptoRail does not decide what to do when step two fails, nor undo step one. That is your business logic. Where several calls must succeed or fail together, the atomicity comes from the chain: an ordered batch from one identity, or a multi-call executed by a smart account in one operation.

Your business operation travels with its transactions: its type, its id and its step appear in queries, events and traces.

Ordered batches from one identity, from the library: consecutive nonces, and the steps behind a failed one cancelled when you ask for it.

An atomic multi-call carries two to sixteen calls, executed all or none by the actor's smart account in one UserOperation; it is refused in plain transaction mode.

flowchart LR
    Y[Your workflow] -->|step 1| CR[CryptoRail]
    Y -->|step 2, if step 1 confirmed| CR
    CR -->|events per step, same operation id| Y
    Y -->|decides retries, compensation| Y

On request

These are designed, have approved requirements and fit behind an existing port, but are built only when a customer asks for them. Each would take its contract tests, and for an external service a documented manual test, before being declared supported.

Events delivered to Kafka, NATS or AMQP brokers. On request

Signing with Azure Key Vault or GCP Cloud KMS, or through Fireblocks. On request

Signing raw messages (personal_sign, EIP-191). On request

Authentication with mutual TLS or OIDC tokens, beside API keys. On request

Generated SDKs for Java, Go and Python, beside the TypeScript one. On request

A reference set of Grafana dashboards and alerts. On request

Until then, the existing paths cover the need: signed webhooks for events, HSM, AWS KMS or your own signer for keys, API keys for authentication, the TypeScript SDK or the OpenAPI document for clients, and OpenTelemetry into the monitoring you already run.

Signed webhooks, retried for about three days, then held in a dead-letter queue an operator can redeliver from.

Your own signer keeps the key: CryptoRail prepares the exact bytes, your system signs them, CryptoRail verifies and broadcasts.

Traces, metrics and structured logs through OpenTelemetry, into the monitoring tools you already run.

Waiting for the external audit

No external security audit has been carried out yet. Two ways of running CryptoRail are offered today: in your own infrastructure, and as a pilot sandbox we operate, which says it is one everywhere and is never supported for value. Running CryptoRail for you in production is built, with a profile that refuses any key of its own, but it is offered only for pilots until that audit is done. The security model lists what the audit must cover.

Runs in your infrastructure, as a container image over your PostgreSQL, with schema migrations applied by an explicit command.

A pilot environment stood up in minutes with nothing installed on your side.

A sandbox says it is one: in its logs, on its health endpoint and on every screen built over it. It is never supported for value.

Run for you in production without ever holding a key of its own: signing stays on your side or in your own cloud account. Available for pilots

The hosted profile refuses to start if it is given a key of its own, listing every reason.

flowchart LR
    SH[Self-hosted] --> OK1[offered today]
    SB[Pilot sandbox] --> OK2[offered today, never for value]
    RF[Run for you in production] --> AU{external audit}
    AU -->|done| OK3[offered]
    AU -->|not yet| PI[pilots only]

What it does not do

This whole page is that section; the other limits worth knowing before a decision are elsewhere:

• Throughput. One worker carries about 25 transactions a second from one identity, against a target of 50 it does not meet; performance and limits has the measurements and the open decision.
• Encryption of operational data at rest is your database platform’s, not CryptoRail’s.
• Load distribution across node endpoints is not done: the others are there for failover.

Evidence

Every claim above links to its evidence on the evidence page. The main ones: