Product

Everything between your systems and the chain, handled.

Your systems describe an operation once. CryptoRail carries it through approvals, signing, gas, nonces, retries and finality, and tells your systems what happened. Every statement below without a badge is tested on every change.

Reliable submissionSigning and approvalsSponsored gasEventsOperationsDeployment

Reliable submission

Transactions that land, exactly once.

A blockchain network drops, delays and reorders transactions. CryptoRail keeps every operation until the network has made it final, replaces what gets stuck, follows reorganisations, and never turns a retry into a second payment.

Submitting the same intent twice with the same idempotency key returns the same transaction: a retry never becomes a second payment.
An operation CryptoRail has acknowledged is never lost: not across crashes and restarts, not through a node outage of up to ten minutes.
Nonces strictly increasing per sending address, gaps detected and filled, and never two transactions mined for one operation.
A transaction the network does not pick up is replaced with a higher fee within the caps you set, or cancelled, never silently abandoned.
An operation is reported confirmed only when the network's finality rule is met; a reorganisation before that is followed, not hidden.
Every failure comes with a report: the stage, a stable cause, whether a retry can work and on what condition, and the suggested action.

flowchart TD
    I[Operation received] --> P{Policy and approvals}
    P --> S[Signed by your signer]
    S --> B[Sent to the network]
    B --> M[Included in a block]
    M --> C[Confirmed, final]
    B -->|not picked up| R[Replaced, higher fee] --> M
    M -->|block reorganised| B

Signing and approvals

Keys stay where they belong.

CryptoRail never holds your keys. It prepares exactly what must be signed, waits for the approvals your policy requires, has it signed where your keys live, and checks the signature before anything leaves.

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.
Your own signer keeps the key: CryptoRail prepares the exact bytes, your system signs them, CryptoRail verifies and broadcasts.
Keys in a hardware security module over PKCS#11 (Thales, Utimaco, Entrust, AWS CloudHSM): tested on every change against SoftHSM2, each vendor declared after a manual test on its device. Built, certification pending
Signing keys in AWS KMS, with the curve checked at startup. Built, certification pending
Operations above a threshold wait for a quorum of approvers, who sign an EIP-712 digest that names neither nonce nor fee.
When required, approvals are enforced on chain by a smart account: the signing key alone cannot move anything.
Declarative policies decide before anything happens: limits per operation, payer and period, held even when several workers decide at once.

flowchart TD
    X[CryptoRail prepares the exact bytes] --> Q{Approval quorum met?}
    Q -->|not yet| W[Waits for the approvers]
    W --> Q
    Q -->|yes| K[Your HSM, cloud KMS or signer]
    K --> V[Signature checked against the address]
    V --> N[Network]

Your customers act on chain without buying gas.

When your end customers have their own accounts, holding gas is the step that loses them. CryptoRail pays it for them, within the budgets you set, using the open standards wallets already speak.

Your end customers act without holding gas: CryptoRail sponsors their operations through ERC-4337 paymasters, and their keys stay in their own accounts.
Wallets ask for sponsorship through the standard ERC-7677 interface, authenticated per application and held to quotas.
Sponsorship budgets that are never exceeded, even under concurrent requests, with the cost attributed to each account and policy.
Only the canonical EntryPoint and public account and paymaster contracts from audited lineages, pinned per network; no custom contract.
Tested with a real wallet on a public test network, beyond the automated tests against a bundler.

flowchart TD
    U[End customer's own account] --> O[Operation, gas not held]
    O --> Y{Your sponsorship policy and budget}
    Y -->|approved| G[Paymaster signs the sponsorship]
    G --> E[EntryPoint executes, your deposit pays the gas]
    E --> T[Cost attributed to account and policy]

Events into your systems

Events your back office can trust.

What happens on chain only matters once your ledger, ERP or customer systems know it. CryptoRail watches your contracts and your own operations and delivers each event, decoded and signed, until your systems have it.

Subscribe to your contracts' events and receive them decoded into named fields, in chain order, once they are deep enough to trust.
Chain reorganisations handled: no event lost or delivered from a discarded block, across restarts.
At-least-once delivery through a transactional outbox, with a deterministic id on every event so your systems can drop duplicates.
Signed webhooks, retried for about three days, then held in a dead-letter queue an operator can redeliver from.
Every change of state of your own operations arrives through the same channel as the contract events.
Events delivered to Kafka, NATS or AMQP brokers. On request

flowchart TD
    C[Contract events and your own operations] --> D[Decoded, deep enough to trust]
    D --> O[(Outbox, same database write)]
    O --> W[Signed webhook]
    W --> B[Your back office]
    W -.->|retries exhausted| L[Dead letter, redeliverable]

Operations and observability

Run it like the rest of your infrastructure.

Built for the team that keeps it running: it reports its own health, explains every failure, scales by adding workers, survives a node going away and plugs into the monitoring you already have.

Traces, metrics and structured logs through OpenTelemetry, into the monitoring tools you already run.
Health and readiness that tell the truth, and a configuration checked at startup with every problem listed at once.
Several node endpoints per network: calls go to the first healthy one, an operation stays on the endpoint it started on, and a dead or lagging node is left aside without losing anything.
Several workers on the same database without sending anything twice.
Your business operation travels with its transactions: its type, its id and its step appear in queries, events and traces.
An operator command line for the daily work: pause an identity, redeliver a webhook, reconcile nonces, export a history, onboard a tenant.
A tenant sees only its own resources, proven on every route of the API on every change.

flowchart TD
    A[API] --> DB[(PostgreSQL)]
    W1[Worker] --> DB
    W2[Worker] --> DB
    IX[Indexer] --> DB
    W1 --> E1[Node endpoint 1]
    W1 -.->|failover| E2[Node endpoint 2]

Deployment choices

Inside your infrastructure, or run for you.

The same product in three shapes, so that a pilot, a self-hosted deployment and a service run for you behave the same. Compare the deployment options.

Embedded as a library in your Node.js application, or run as a service with an HTTP API described in OpenAPI and generated SDKs.
Runs in your infrastructure, as a container image over your PostgreSQL, with schema migrations applied by an explicit command.
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
A pilot environment stood up in minutes with nothing installed on your side.