Transaction pipelines · Bridge orchestration · AI trading agents
Crypto workflows that survive crashes, deploys, and chain reorgs.
A failed retry in crypto can cost $1M. Orch8 is a Rust-based durable workflow engine with snapshot recovery, per-resource rate limiting, and memoized step outputs — so transactions never execute twice.
The problem
80% of crypto engineering pain is off-chain.
Your smart contract is 500 lines. The off-chain infrastructure that monitors, triggers, retries, rate-limits, and recovers from failures is 50,000 lines of fragile custom code.
Duplicate transactions after crashes
Your node restarts mid-pipeline. The transaction was broadcast but the result wasn't saved. Without memoization, it executes again — double-spending, double-minting, or double-swapping.
RPC rate limits burn your provider
Alchemy, Infura, and QuickNode all enforce per-second limits. A burst of on-chain reads during a liquidation event exhausts your quota and blinds your system at the worst possible moment.
No branching for confirmation states
Transaction pending? Confirmed? Reverted with a specific error code? Each state requires a different follow-up action — and your cron job treats everything the same way.
Multi-chain flows are fragile
Bridge workflows span two or more chains: lock on chain A, wait for finality, mint on chain B, confirm. If any step fails mid-flow, the entire bridge operation hangs in limbo.
AI agents lose context on restart
Your trading agent analyzed 50 tokens, ranked strategies, and was about to execute — then the container restarted. All reasoning, all intermediate state, gone. Starts from scratch.
Compliance workflows are manual
KYC checks, sanctions screening, transaction monitoring — each step is a different service with its own latency. Stitching them into a reliable pipeline takes months of custom code.
Use cases
Every crypto workflow. One engine.
Orch8 is a general-purpose durable workflow engine. These are the crypto and DeFi workloads teams reach for it most.
Transaction pipelines
Submit, confirm, and retry — without double-spending
Build a tx submission pipeline that estimates gas, submits the transaction, polls for confirmation, and retries with escalating gas on timeout. Memoized outputs guarantee the transaction is never broadcast twice, even if the engine crashes mid-step.
Cross-chain bridge orchestration
Lock, finalize, mint, confirm — across any number of chains
Orchestrate multi-chain bridge flows: lock tokens on chain A, wait for finality (configurable block depth), mint on chain B, verify the mint succeeded. If any step fails, the pipeline pauses and alerts — no tokens stuck in limbo.
Airdrop distribution
Distribute to 100K wallets without hitting rate limits
Batch wallet addresses into groups. Submit transactions with per-resource rate limits so you never exceed RPC quotas. Track each batch independently. Resume from the exact checkpoint after any interruption — no wallet receives tokens twice.
KYC/AML compliance
Identity verification pipelines that never lose state
Chain identity checks, sanctions screening, document verification, and manual review into a single durable pipeline. If the sanctions API is down, the step retries with backoff. If a human reviewer is needed, the pipeline waits. Full audit trail for every decision.
Treasury rebalancing
Monitor, calculate, approve, execute — on schedule
Run portfolio monitoring on a cron schedule. When allocations drift beyond thresholds, calculate rebalancing trades, route through a human approval gate for large amounts, then execute with rate-limited order submission. Crash-safe across the entire multi-step flow.
AI trading agents
Crash-safe agents that reason, trade, and wait for review
Build AI agents that analyze market data, generate trading strategies, and execute orders — with built-in crash durability. If the agent crashes after 3 hours of analysis, it resumes from the last checkpoint with all reasoning intact. Human approval gates before large trades.
How it works
Three steps to a crash-safe transaction pipeline
Define your transaction pipeline as JSON
Describe the steps, delays, conditions, and retry logic in a JSON sequence definition. No SDK lock-in. No new programming model. Your handlers are plain HTTP endpoints in any language.
{
"id": "evm_tx_pipeline",
"blocks": [
{
"type": "step",
"handler": "estimate_gas",
"retry": { "max_attempts": 3, "backoff": "1s" },
"rate_limit_key": "rpc:alchemy",
"rate_limit": { "max": 25, "window_seconds": 1 }
},
{
"type": "step",
"handler": "submit_transaction"
},
{
"type": "loop",
"condition": "{{outputs.confirm_tx.status == 'pending'}}",
"max_iterations": 30,
"blocks": [
{
"type": "step",
"handler": "confirm_tx",
"delay": { "seconds": 12 }
}
]
},
{
"type": "router",
"routes": [
{
"condition": "{{outputs.confirm_tx.status == 'reverted'}}",
"blocks": [
{ "type": "step", "handler": "handle_revert" }
]
},
{
"default": true,
"blocks": [
{ "type": "step", "handler": "log_success" }
]
}
]
}
]
}Deploy workers in any language
Workers are plain HTTP handlers. Orch8 calls them via a pull-based REST API. Write them in TypeScript with ethers.js, Python with web3.py, Go with go-ethereum — anything that can respond to a POST request.
// TypeScript worker — submit EVM transaction
app.post('/workers/submit_transaction', async (req, res) => {
const { context } = req.body;
const wallet = new ethers.Wallet(
process.env.PRIVATE_KEY,
provider
);
const tx = await wallet.sendTransaction({
to: context.data.to,
value: ethers.parseEther(context.data.amount),
gasLimit: context.data.gas_estimate,
});
// Output is memoized — if engine crashes after this,
// the tx hash is preserved, never re-broadcast
res.json({ tx_hash: tx.hash, status: 'pending' });
});Create instances from your API or on-chain events
Start a pipeline instance from a webhook, an on-chain event listener, a cron schedule, or a manual trigger. Orch8 schedules and tracks execution from start to finish. Idempotency keys prevent duplicate pipeline creation.
POST /sequences/evm_tx_pipeline/instances
{
"context": {
"data": {
"to": "0x742d35Cc6634C0532925a3b844Bc9e7595f2bD28",
"amount": "1.5",
"chain_id": 1,
"gas_estimate": 21000
}
},
"idempotency_key": "transfer-order-8291"
}Why Orch8 for crypto
Memoized outputs prevent duplicate transactions.
When a step completes, its output is persisted before the next step begins. If the engine crashes and recovers, it returns the cached result instead of re-executing. Your submit_transaction handler runs exactly once — even across crashes, deploys, and restarts.
- ✓Output memoization — tx hash is saved before moving to the next step
- ✓Snapshot recovery — resume from last checkpoint, no event replay
- ✓Idempotency keys — prevent duplicate pipeline creation from the same event
- ✓Per-resource rate limits — respect RPC quotas per provider, per chain
- ✓Signals — pause, resume, or cancel running pipelines via REST API
- ✓Written in Rust — the language crypto trusts for performance-critical infrastructure
Cross-chain bridge — simplified
{
"id": "bridge_eth_to_arb",
"blocks": [
{
"type": "step",
"handler": "lock_tokens_l1",
"retry": { "max_attempts": 3, "backoff": "5s" }
},
{
"type": "loop",
"condition": "{{outputs.check_finality.finalized == false}}",
"max_iterations": 100,
"blocks": [
{
"type": "step",
"handler": "check_finality",
"delay": { "seconds": 12 }
}
]
},
{
"type": "step",
"handler": "mint_tokens_l2"
},
{
"type": "step",
"handler": "verify_mint_l2"
}
]
}What happens on crash
Feature map
Built for financial-grade reliability
Every Orch8 feature maps directly to a crypto infrastructure requirement. Nothing is bolted on — it was designed for workloads where failure is expensive.
Crash recovery with snapshot persistence
Transaction pipelines that survive node restarts without duplicate txs. No event replay overhead — resume instantly from the last checkpoint.
Per-resource rate limiting
Respect RPC rate limits per provider (Alchemy, Infura, QuickNode) and per chain. Overages are deferred to the next available slot — never dropped.
Conditional branching (Router blocks)
Different paths based on tx confirmation status, gas price thresholds, slippage tolerance, or chain-specific error codes.
Retry with exponential backoff
Failed tx resubmission with escalating gas prices. Configurable max attempts and backoff intervals per step.
Parallel execution
Multi-chain monitoring, batch wallet operations, concurrent price checks across DEXes — all running simultaneously within a single pipeline.
Human approval gates
Large trade approvals, multi-sig coordination, compliance reviews. Pipeline pauses until a human signals approval via REST API.
AI agent loops with crash durability
Trading strategy agents, portfolio rebalancing agents, on-chain research agents — all crash-safe with memoized LLM outputs.
Signals (mid-execution control)
Emergency stop on all trading workflows. Pause airdrop distribution. Resume after maintenance. Cancel a bridge flow mid-execution.
Time-aware scheduling
Market-hours-aware execution, funding rate arbitrage timing, settlement window scheduling. Cron-triggered with IANA timezone support.
Multi-tenancy
White-label for crypto platforms serving multiple traders, DAOs, or institutional clients. Isolated execution contexts per tenant.
Full audit trail
Every step execution, every output, every retry is persisted. Regulatory compliance for MiCA, SEC reporting, and internal risk management.
Written in Rust
The language crypto teams trust for performance-critical infrastructure. 1M+ concurrent workflow instances per node. Single binary deployment.
What you don't build
6 problems you never have to solve
Every crypto team that runs transaction pipelines eventually builds all of these. With Orch8, none of them are your problem.
Transaction deduplication logic
No tracking whether a tx was already broadcast before the crash. Orch8 memoizes step outputs — retries return the cached tx hash, never re-broadcast.
RPC rate limit enforcement
No Redis-backed counters per provider. Set a rate_limit_key and a limit on any step. Orch8 tracks usage with a sliding window and defers overages automatically.
Multi-chain state machine
No custom code tracking which chain is at which step. Define the full cross-chain flow as JSON blocks. Orch8 manages the state across restarts.
Crash recovery for long-running monitors
No heartbeat polling, no stuck-job detector. Instances stalled mid-execution are auto-reset on engine restart and resume from the last checkpoint.
Confirmation polling infrastructure
No custom loop-and-sleep logic for tx confirmation. Use a Loop block with a delay — Orch8 handles scheduling, retry, and crash recovery natively.
Audit logging for compliance
No separate logging pipeline. Every step execution, output, retry, and signal is persisted in PostgreSQL. Query it directly for compliance reports.
Comparison
Orch8 vs Temporal for crypto workflows
Temporal is powerful but heavyweight. For crypto teams that need durability without determinism constraints and operational complexity, Orch8 is the simpler path.
Recovery model
Temporal
Event history replay — replays entire workflow history on recovery. Long-running monitors slow down over time.
Orch8
Snapshot persistence — resumes from the last checkpoint instantly. No replay overhead, no matter how long the workflow has been running.
Determinism constraints
Temporal
Workflow code must be deterministic. Cannot call RPC nodes, read timestamps, or generate random values directly in workflow code.
Orch8
No determinism constraints. Handlers are plain HTTP endpoints. Call RPC nodes, read price feeds, sign transactions — directly in your handler code.
Operational complexity
Temporal
Requires a separate Temporal cluster (history, matching, frontend services). Most crypto teams need a dedicated DevOps hire to manage it.
Orch8
Single Rust binary. Runs on SQLite for development, PostgreSQL for production. No cluster, no Java dependencies, no separate services.
Rate limiting
Temporal
No built-in per-resource rate limiting. Teams build custom rate limiters on top of activity retry logic.
Orch8
Native per-resource rate limiting with sliding window. Set a rate_limit_key per RPC provider, per chain, per exchange. Overages deferred, never dropped.
Language
Temporal
Temporal server: Go. SDKs: Go, Java, TypeScript, Python, PHP, .NET. Worker code has SDK-specific constraints.
Orch8
Engine: Rust. Workers: any language via REST. Official SDKs for Node.js, Python, Go. No SDK-specific constraints on handler code.
Your transaction pipeline shouldn't be your biggest risk.
Tell us what you're building. We'll reach out within 24 hours to walk you through a working example for your crypto workflow — bridge orchestration, airdrop distribution, compliance pipeline, or trading agent.
No credit card required. Self-host free with no feature gates.