Deep dives

For the engineers, architects and security reviewers evaluating CryptoRail: how each part works, what it guarantees, what it does not do, and the evidence.

• How to read these deep dives: What each deep dive covers, what a status label means, and where the evidence is. (everyone evaluating CryptoRail)
• Architecture: A core library with a thin service around it, a port for every external concern, four topologies from one codebase, and processes that share nothing but the database. (architects)
• The life of a transaction: From the intent to the confirmed operation, a state machine written as data, idempotency, nonce management and gap repair, gas policies and priority tiers, stuck detection and replacement, finality per network, and the failure report. (platform engineers)
• Signing, custody and approvals: Three signer levels behind one port, HSMs over PKCS#11, AWS KMS, your own signer, approvals by quorum as EIP-712 signatures checked by a signing gate, and on-chain enforcement with guarded smart accounts. (security teams and architects)
• Security model and trust boundaries: What each process can and cannot reach, database least privilege, secrets by reference, API keys under a pepper, signed webhooks, the three deployment profiles and what each admits and refuses, and what the external audit still to come must cover. (security reviewers)
• Sponsored execution: Paying the gas of your end customers' operations while they keep their own keys, through ERC-4337 with a verifying paymaster, ERC-7677 for wallets and EIP-7702 onboarding, with sponsorship policies, quotas and the cost of every operation attributed. (product and blockchain engineers)
• Events and integration: How your systems learn what happened, on the chain and inside CryptoRail, through subscriptions to contract events that survive reorganisations, a transactional outbox, signed webhooks with retries and dead letters, and exports for audit. (integration engineers)
• Operations and multi-tenancy: What an operations team runs and watches, health and readiness, structured logs, traces and metrics through OpenTelemetry, failover between node endpoints, tenant isolation and how it is proven, quotas, the operator command line and the runbooks. (operations teams)
• Networks and compatibility: Public and permissioned EVM networks, network profiles, free-gas consortium networks on Hyperledger Besu, what is tested on every change and against which versions, the pinned contracts, the networks the pilot packs ran on, and what is not supported. (architects)
• Performance and limits: What has been measured and how, what scales by adding workers, the limits we know about, and the throughput question that is still the product owner's to decide. (architects and buyers)
• What CryptoRail does not do: What is out of scope by design and why, what is built only when a customer asks for it, and what waits for the external security audit. (everyone technical)
• Security questionnaire: Short answers to the questions a vendor security assessment asks, grouped the way common questionnaires group them, each pointing at its evidence, with the answers that are "no" or "not yet" said plainly. (security reviewers)
• Pilot playbook: How your engineers evaluate CryptoRail on our sandbox, which is never for value - what to try and in what order, how to read the journeys report, and how a pilot becomes your own deployment. (the prospect's engineers)