Rust & Solana engineering consultancy · London

A blocking integration should not be the reason you miss your launch.

EpochFi Labs helps startups and protocol teams design, build, integrate, and harden production financial systems on Solana. Senior-led Rust engineering, with one engineer accountable for the whole system — not a ticket queue.

Available for new engagementsDirect to the engineer doing the work. No account managers.
Order lifecycle · failure pathfig. 01
intent acceptedidempotency key issued
venue adapter · submitbounded retry
connection lost mid-submitstate unknown
reconciliation sweepvenue is source of truth
position convergesdeterministic recovery

Most prototypes model steps 1 and 2. Production systems lose money at step 3. The work is designing 4 and 5 before an incident forces you to.

Epoch clock
0slots since you opened this page
400 ms per slot · 432,000 slots per epoch
Your system has 400 ms to be right.
11 yrs
building financial systems
Bank-side
JP Morgan rates pricing · NatWest trade data · Caplin FX & commodities
380k
lines of production Rust shipped
2,900+
tests across two live Solana systems
1:1
you work with the engineer, directly

In plain terms: I am the senior engineer teams bring in when their Solana product has to work with real money.

Who I work with
Solana dAppsDeFi protocols & integratorsMarket makersTrading applicationsFintechs exploring stablecoins & settlement

Typically three to fifty people, pre-seed to Series A, with money or user positions already moving through the system — or about to be.

01 · Problems

The point where shipping fast stops being enough.

If one of these describes your position, the conversation is usually short and specific.

An exchange, venue, or protocol integration is blocking your launch.

Third-party APIs fail in ways documentation does not describe: partial fills, silent rejections, duplicate acknowledgements, geo-blocks, sockets that stay open for hours while sending nothing. I have built and repaired integrations across seven venues, and I know which failure modes must be designed for before launch rather than after.

Your prototype works, but it is not ready for real money or real users.

A demo only has to succeed once. A production financial system has to be correct when a transaction is dropped, a worker restarts mid-operation, or a venue returns a state you did not anticipate. That gap is architecture, not effort.

Orders, transactions, or positions get stuck when something external fails.

Stuck state is expensive twice: once in exposure, once in the engineering hours spent reconstructing what happened. The fix is idempotent operations, an explicit source of truth, and recovery paths that run without a human deciding what to do.

You need senior Rust or Solana expertise without making a permanent hire.

Hiring a senior Rust engineer in this domain takes months and commits you to a salary before you know the shape of the work. An engagement gives you the same seniority on a defined scope, and ends when the work is done.

AI is generating more code than your team can safely review.

Generated Rust usually compiles and often passes the happy path. What it rarely gets right is concurrency, error propagation, state consistency, and what should happen when a call fails halfway. I review that code and the architecture around it.

02 · Services

Four areas of work

Most engagements combine two of these: build the thing, then make it survive production.

A

Solana & Rust engineering

Anchor programs, the Rust backend services around them, and the instruction-building SDKs your clients call — written to be read and maintained by your team after I leave.

  • Anchor program development
  • Rust backend services (Axum, Tokio)
  • Protocol integrations
  • Instruction builders & client SDKs
  • Transaction construction & submission
  • Account & state architecture
  • Geyser / Yellowstone gRPC pipelines
  • Performance & compute optimisation
Stack
RustAnchorTokioAxumsolana-sdksolana-clientYellowstone gRPCBorshSPL
B

DeFi & trading infrastructure

The parts of a financial product where correctness is commercial: what a position is, when it settles, and what happens when a venue disagrees with you.

  • Order & position lifecycle management
  • DeFi protocol integrations
  • Exchange & liquidity venue integrations
  • Liquidation workflows
  • Settlement & reconciliation
  • Market-data & price-feed services
  • Real-time event processing
  • Perpetuals, AMMs & prediction markets
Stack
PhoenixJupiterDriftPythChainlinkMagicBlock ERJito · HeliusRedisPostgresClickHouse
C

Architecture & production hardening

A read of the system as it actually is, followed by a prioritised plan to make it dependable. Engineering review, not a formal security audit.

  • Architecture & codebase reviews
  • Concurrency & async Rust analysis
  • Failure recovery design
  • Idempotency & state consistency
  • Testing strategy
  • Monitoring & operational tooling
  • Incident investigation
  • Production-readiness review
Stack
async RustTypeScripttracingtestcontainerswiremockcargo-denyAnchor testsKubernetes · AWS
D

Embedded technical leadership

For founders without a senior engineer in the room: someone accountable for technical decisions, and able to explain them commercially.

  • Fractional technical leadership
  • Senior individual-contributor support
  • Architecture ownership
  • Technical planning & roadmapping
  • Code review, including AI-generated code
  • Engineering-process improvement
  • Mentoring & decision support
Stack
RustTypeScriptNext.jsNestJSweb3.js · ViemJavaSolidity · Foundry
03 · Selected work

Two production Rust systems

Both sit behind a live mobile perpetuals and prediction-market product on Solana. Repositories are private; technical detail available under NDA.

CASE 01ASYMMETRA LABSREAL-TIME MARKET DATA

A price platform that degrades instead of going dark

Problem

A mobile trading product needed prices from seven heterogeneous venues, on-chain and off, delivered to phones fast enough to trade against. Each venue fails differently, and a chart that freezes or lies is a support ticket at best and a bad fill at worst.

Responsibilities

Sole engineer on the service: protocol specification, venue ingestion, storage design, deployment topology, and the operational tooling around it.

Approach

Independent Tokio tasks per venue with backoff reconnect and liveness watchdogs, funnelling into a bounded channel that deliberately drops stale ticks under backpressure — the correct failure mode for price data. Per-symbol transport precedence lets on-chain marks own a symbol while fresh and hand back to the venue socket when they age out, so an outage degrades quality rather than emptying a chart. A database-driven market registry means new markets go live without a deploy. Prices are served over a documented WebSocket contract with snapshot-first ordering guarantees, so the mobile client needs no buffering, deduplication, or staleness logic of its own.

Outcome

Removed the single-transport dependency behind price outages, cut on-chain ingress roughly eightfold by slicing account frames server-side, and made market listing an operational action rather than an engineering one. 263 tests, none ignored, including wire-protocol assertions taken directly from the specification.

In numbers
venues ingested7+
storage tiers3
on-chain read latency~50 ms
tests · ignored263 · 0
TODO / FIXME / HACK0
Stack
Rust · TokioYellowstone gRPCPythMagicBlock ERRedisPostgresWebSocket
CASE 02ASYMMETRA LABSTRADING BACKEND

Funds-safety engineering on a live derivatives backend

Problem

Real money moving through perpetuals, a hosted-perps router across four venues, prediction markets, and a high-leverage sixty-second game — with custodial wallets and no tolerance for a position ending in an unknown state.

Responsibilities

Backend architecture and delivery: transaction construction, job execution, venue integrations, reconciliation tooling, and post-incident redesigns.

Approach

Every high-risk module states the invariant it protects. The market registry fails closed rather than defaulting to a wrong account slot. Withdrawal sweeps only write a terminal record after funds are confirmed home; on exhaustion the position stays open, ops are alerted, and a reconciler re-enqueues it. Protective stop and take-profit legs are placed and confirmed before the previous ones are cancelled, so a failed reset can never strip existing protection. Expiry and liquidation are made mutually exclusive by a database write-fence. A gasless-transaction incident was closed by re-specifying the budget in terms of confirmed sponsorships and deploying it under a new key namespace, so stale semantics could not survive the release.

Outcome

Introduced deterministic recovery paths across every funds-moving workflow, replaced silent defaults with explicit refusals, and gave the team paging that fires once per incident instead of not at all. A real-funds mainnet harness with cent-level conservation assertions makes release verification repeatable rather than a judgement call.

In numbers
lines of Rust~380k
API routes288
ops binaries38
test functions~2,700
TODOs in 380k lines32
Stack
Rust · AxumAnchorPhoenixJupiterJito · HeliusSupabasePrivy

[VERIFY] Testimonial from Asymmetra Labs — two or three sentences on what was delivered and what changed as a result. Ask for something specific rather than complimentary.

[VERIFY] Name, role — Asymmetra Labs
Discuss a similar system
04 · Engagement models

Three ways to start

Most clients begin with a review, because it makes the rest of the work accurately scopeable.

I. ENGINEERING REVIEW

A focused assessment of an existing codebase, architecture, integration, or production concern.

Deliverables
  • Technical findings
  • Risk assessment
  • Prioritised recommendations
  • Remediation plan
  • Architecture diagrams
  • Implementation roadmap
Fixed fee · 1–2 weeks
II. DELIVERY SPRINT

A defined engagement to build a specific subsystem, integration, protocol component, or production improvement.

Phases
  • Discovery
  • Architecture
  • Implementation
  • Testing
  • Deployment support
  • Documentation & handover
Scoped fee · typically 4–8 weeks
III. EMBEDDED PARTNER

Ongoing senior engineering support for teams that need architectural and delivery ownership alongside their own engineers.

Shape
  • Part-time or full-time
  • Monthly retainer
  • Architecture ownership
  • Code & AI-code review
  • Technical planning
  • Rolling monthly renewal
Monthly retainer · min. one month

[VERIFY] Indicative pricing sits well here — a single "from" figure per model filters enquiries before they reach your calendar. Add it once you are comfortable publishing numbers.

05 · Approach

How I build systems that hold money.

Five principles that decide most of the design work before any code is written.

01

Name the source of truth

For every piece of state — a position, a balance, an order — one system decides. Everything else reconciles towards it. Ambiguity here is the root of most financial-system incidents.

02

Fail closed, never on a default

A lookup that cannot answer must refuse the work, not guess. Silent defaults in a funds path are how one market's position ends up written against another's account.

03

Design recovery, do not improvise it

Partial failure is a normal operating condition, not an exception. Idempotency keys, reconciliation sweeps, write-fences, and compensating actions belong in the design, so recovery does not depend on who is awake.

04

Instrument for the incident you will have

Logs, metrics, and alerts built around the business workflow rather than the request. The test is whether one engineer can answer "what happened to this order" in minutes, and whether anyone gets paged when the answer is bad.

05

Leave your team able to own it

Written specifications, documented decisions, tests that describe intent, and a handover walkthrough. The engagement is finished when the system does not need me.

portrait — plain dark background,
neutral, no crypto backdrop
06 · Who you work with

Liam Faruq

Founder & principal engineer, EpochFi Labs Ltd · London

I spent the first part of my career inside bank technology: trade-event feeds and data services at RBS and NatWest Markets, then rates pre-trade pricing at JP Morgan, building concurrent Java systems for OIS, swaps and swaptions. After that, full-stack work on a consumer lending platform, and FX and commodities settlement tooling in Rust at Caplin Systems. Since 2024 I have worked exclusively in Rust and Solana, contracting with protocol and trading teams.

That sequence is the point of EpochFi Labs. Trading, settlement and reconciliation have well-understood failure modes in traditional finance, and much of the Solana ecosystem is rediscovering them at cost. I bring that discipline into on-chain engineering, without the overhead of a large consultancy.

EpochFi Labs is deliberately senior-led and small. You speak to the engineer who writes the code, scopes the work, and answers for it in production. When an engagement needs additional hands, I say so before we start.

2024 — nowRust & Solana contracting — Asymmetra Labs, Ranger Finance and other protocol teams
2024Caplin Systems — FX and commodities trading tools in Rust for tier-one banks
2022 — 2024Deko Pay — full-stack engineering on a retail credit platform
2019 — 2021JP Morgan Chase — rates pre-trade pricing, concurrent Java
2015 — 2019RBS & NatWest Markets — trade-event feeds, batch processing, data services
EducationMEng Electronics & Computer Engineering, University of Nottingham — Siemens sponsored
07 · Technical notes

Writing, monthly

[VERIFY] Publish the first two before this section goes live. Drafts to follow if useful.

PRODUCTION DEFI

Why DeFi prototypes fail in production

The five states a demo never has to handle, and what each one costs when real positions are open.

RUST & ASYNC

Reviewing AI-generated Rust

Where generated concurrency and error handling quietly diverge from what the business needs.

SOLANA

Transaction reliability on Solana

Confirmation, retries, and the difference between submitted and settled.

08 · Next step

Tell me what you are building.

Thirty minutes, no obligation. Bring the integration that is blocking you, the subsystem you are unsure about, or the repository you would like read. You will leave with a view on scope and risk whether or not we work together.

[VERIFY] Wire the primary button to a Cal.com or Calendly link before launch.

Useful to include
  • What you are building, and who it is for
  • Where the system is today: prototype, devnet, or live
  • The problem you would most like solved first
  • Any date the work is tied to
  • Your team's current Rust and Solana experience

Happy to sign an NDA before reviewing anything.