Execution runtime for institutional finance on Solana

Your trading systems decide. Octoarka executes, on Solana.

Octoarka is the execution layer institutions deploy beneath their trading systems. It carries approved financial actions through execution, observation and reconciliation on Solana, without replacing the systems you already run.

Contact us See the evidence

v0.2.0 releasedRunning on Solana DevnetEvidence published on-chain

  1. approved
  2. accepted
  3. authorized
  4. signed
  5. recorded
  6. submitted
  7. observed
  8. finalized
  9. reconciled

The problem

Submitting a transaction is not settling a trade.

When the reply to a payment goes missing, nobody knows whether it happened. Between two institutions, both obvious reactions are wrong.

Send againand the trade may be paid twice.
Do nothingand it may never happen at all.
Guessand the books no longer match what the chain did.
“A successful response from this method does not guarantee the transaction is processed or confirmed by the cluster.”
Solana documentation,
sendTransaction RPC method

The vision

One execution runtime. Every financial workflow on Solana.

Trading systems decide what to trade. Custody holds the keys. Solana executes. Between them, someone has to own the execution itself and the evidence of what happened. Octoarka is that layer: deployed on the institution’s own infrastructure, the same engine for every protocol, each financial workflow added as an adapter.

Institution's trading systemsDecide what to trade
Strategy & riskOMS / EMSTrading applicationsFIX-based systems · R&D
approved instructionstatus, report & evidence
Octoarka execution runtimeCarries it out · proves it
NorthboundgRPC API
FIX gateway · R&D
One lifecycle for every action
  1. admit
  2. authorize
  3. plan
  4. build exact message
  5. sign
  6. record
  7. submit
  8. observe
  9. recover
  10. reconcile
  11. report
Durable journalevery step recorded before the next
Protocol adapters DvP settlementSpot order bookAMM / CLMMRoutingLendingDerivativesTokenised assets
Operator controlsReadinessAuditKill switch
Institution's signerCustody stays with you

Signs the exact authorized bytes. Keys never enter Octoarka.

Test signer · todayHSM / KMS / MPC · planned

exact signed transactionsauthoritative on-chain evidence
Solana programs & networkThe authority on-chain
Settlement programsOrder booksOctoarka Execution GuardAccounts & token state
Implemented in v0.2.0PlannedR&D

The institution keeps

  • Strategy, risk and trading systems
  • Custody and key authority
  • Deployment and accounting

Octoarka owns

  • The execution lifecycle of each action
  • Authorization bound to exact bytes
  • Recovery, reconciliation and audit

Solana remains

  • The authority for on-chain execution
  • The source of truth for state
  • Where the evidence is read from

The product family

One engine. Every workflow is an adapter.

The lifecycle, journal, signer boundary and reconciliation are shared. Two adapters are implemented and proven on Solana Devnet; the rest are the stated direction, not delivered features.

Implemented

Planned

R&D

Implemented · v0.1.0

Atomic DvP settlement

Settles an existing delivery-versus-payment trade whose two legs are already in escrow. Octoarka verifies the trade on-chain, authorizes the exact settlement transaction, has the institution’s signer sign it and reconciles both legs independently.

  • Asset and payment move in one transaction, or not at all
  • A deliberately discarded reply was recorded UNKNOWN and resolved after a restart, with exactly one transaction sent
  • Submitted through the audited API by a trading application
DvP via API · MATCHED ↗Lost reply recovered · MATCHED ↗

Uses an existing Solana DvP program; Octoarka does not hold the escrow. Devnet only.

Implemented · v0.2.0

Spot order-book execution

Immediate-or-cancel orders on an on-chain central limit order book, with an average-price limit. Every order is one atomic transaction wrapped by the Octoarka Execution Guard, our own Solana program: the chain itself refuses a second execution of the same order and any fill beyond the limit.

  • Outcomes proven on Devnet: MATCHED, PARTIAL, and FAILED proven not executed
  • A duplicate of an executed order was refused on-chain by the Guard
  • Kill switch: paused admission refuses new orders, audited
Order · MATCHED ↗Order · PARTIAL ↗Execution Guard program ↗

Devnet only; market liquidity from our own demo maker. Resting limit orders and cancels are planned, not built.

Planned

AMM and concentrated liquidity

Execution against automated market makers and concentrated-liquidity pools, through the same lifecycle, signer boundary and reconciliation as today’s adapters.

  • Quote, slippage bound and pool state resolved from the chain before signing
  • Reconciled against the amounts that actually moved

Planned. Not built.

Planned

Multi-venue routing

One approved instruction, routed across venues and reconciled as one economic outcome, with every leg on the evidence record.

  • Each leg carries its own attempt and observation evidence
  • One report for the instruction your systems sent

Planned. Not built.

Planned

Lending and borrowing

Collateral deposits, loans and repayments as tracked, recoverable and reconciled executions.

  • Position changes reconciled against program state
  • The same authorization and audit trail as settlement

Planned. Not built.

Planned

Derivatives

Perpetuals and other derivative workflows on Solana programs, under the same execution guarantees.

  • Exact-message authorization for every order
  • UNKNOWN outcomes resolved from chain evidence, never guessed

Planned. Not built.

Planned

Tokenised and regulated assets

Support for Token-2022 controls such as transfer hooks, which regulated instruments rely on.

  • Today these token extensions are refused by policy
  • Support is planned as a reviewed, explicit decision

Planned. Not built.

R&D

FIX connectivity

A FIX gateway beside the gRPC API, so existing trading software can reach Solana through the messages it already speaks, without Solana-specific code.

  • Orders in, execution reports out, mapped to the Octoarka lifecycle
  • Research direction: no delivery date and no commitment

R&D. Not built.

How it works

Seven guarantees, the same for every action.

Whatever the protocol, every action passes through one lifecycle. Each step is written to a durable journal before the next one starts, so the full story can be explained and checked afterwards.

01

Durable acceptance

The instruction is recorded on disk before anything else happens. A retry with the same ID returns the same execution, never a second one.

02

Verified against the chain

Everything the instruction refers to is read from Solana and checked. Nothing is trusted on faith.

03

Authorized twice

First the plan, then the exact bytes to be signed. A swapped account or an extra instruction is refused.

04

External signing

Your signer holds the keys and signs only the authorized message. Octoarka verifies every signature itself.

05

Record before send

The signed transaction is saved before it is sent, so a crash never loses track of what went out.

06

UNKNOWN is never “failed”

A lost reply is resolved from Solana’s own records after a restart. Nothing new is built while an outcome is open.

07

Independent reconciliation

What actually moved is compared with what was agreed, leg by leg, and reported with its evidence and an audit trail.

→

The result

instruction → exact bytes signed → what Solana did → whether it matched.

Built to be operated

Runs on your infrastructure, under your control.

Operator terminal

Readiness, every execution with its lifecycle and chain evidence, an attention queue, the audit log and the kill switch. Every command needs a reason and is recorded.

Reference trading app

A trading desk that places orders and settlements through the API, the way your own systems would. It holds no keys and sends nothing itself.

Linux packages

Ubuntu packages with sandboxed system services, reproducible builds and an external signer boundary. No keys or secrets ship in a package.

Octoarka operator app: Overview Octoarka operator app and Octoarka Desk side by side Octoarka Desk: DvP settlement Octoarka Desk: order book and execution tracker

Evidence, not claims

Measured on Solana Devnet, published on-chain.

Every number below comes from the runtime’s own journal or from finalized transactions you can look up yourself.

~9 saccepted to final reconciled report for an order, on Devnet
9–20 mssigner round trip; policy checks take about 15 ms
1transaction sent after a deliberately lost reply. Zero resends.
0keys inside Octoarka. Signing stays with the institution.

Single runs on Solana Devnet through one RPC provider; not a production performance claim. The lost reply was injected on purpose.

All proofs and benchmarks

Roadmap · a plan, not a promise

From a proven engine to institutional infrastructure.

Now · implemented

Proven on Devnet

Execution engine
  • Lifecycle, durable journal, recovery, reconciliation, audit
Protocol adapters
  • Atomic DvP settlement
  • Spot order book, immediate-or-cancel
  • On-chain Execution Guard
Operations
  • Operator terminal and kill switch
  • Reference trading app over the API
  • Reproducible Ubuntu packages
Next · planned

Broader execution, same core

Order-book lifecycle
  • Resting limit orders
  • Amendments and cancels, lifecycle-tracked
Protocol adapters
  • AMM and concentrated liquidity
  • Additional order-book venues
Connectivity and resilience
  • Multiple RPC providers
  • Broader failure drills
Evaluation
  • Design-partner technical evaluations
Later · planned & R&D

Institutional integration

Protocol adapters · planned
  • Routing, lending, derivatives
  • Tokenised and regulated assets
Institutional signers · planned
  • HSM, KMS and MPC integrations
  • Enterprise single sign-on
Deployment · planned
  • High-availability deployment
  • Container packaging
Research · R&D
  • FIX connectivity for existing trading software

Octoarka is not an OMS or EMS, an exchange, a custodian, a wallet, a market maker or a blockchain. It integrates with existing Solana programs and your existing systems.

Evaluating on-chain execution for your institution?

Talk to us about a technical evaluation, an integration or the roadmap.

Contact us