TriFi · engineering
Software for when the consequences are real
Crypto, blockchain, AI and web3 work is easy to demo and hard to operate. We build the second kind: systems that run unattended, hold value, integrate with protocols that will not wait for you, and keep working after the person who wrote them stops watching.
- DomainsCrypto · Blockchain · AI · Web3
- ProofOur own live capital
- Default postureTests around every dollar path
- HandoverYour repo, your keys
Capabilities
What we take on.
Six areas where the work is genuinely hard and the failure modes are expensive. Most engagements touch two or three of them at once, because that is how real products are shaped.
Autonomous trading & treasury systems
Long-running strategy daemons, capital allocators, execution routing, risk rails and reconciliation harnesses — the machinery that lets software operate a book without a person watching it. This is the discipline the Tokenized Asset Manager is built from.
- allocation engines + directive protocols
- mechanical risk rails and circuit breakers
- PnL reconciliation + realised-cost attribution
- multi-wallet isolation and treasury sweeps
AI decision layers you can ship
Getting a model to answer well is the easy half. We build the other half: structured outputs validated against a schema, retries and cross-model fallback, per-call cost accounting, prompt and response quality monitoring, and deterministic guardrails on every consequential action.
- structured advisors + schema validation
- retry, model fallback, cost accounting
- agent loops with human decision gates
- prompt + response quality monitoring
Protocol & DeFi integration
Direct integration with the protocols that actually hold the capital — DEX routing and aggregation, concentrated liquidity, lending and leverage vaults, staking and liquid-staking tokens — plus the unglamorous RPC and transaction-reliability layer underneath all of it.
- swap routing + slippage control
- LP, lending and leverage position management
- RPC failover + transaction reliability
- token safety checks before capital moves
Token & web3 product surfaces
The user-facing half of an on-chain product: wallet-native front ends, mint and distribution flows, staking and vesting interfaces, and the privacy, terms and consent surfaces that have to ship at the same time rather than afterwards.
- wallet connection + on-chain UX
- mint, vesting and staking interfaces
- privacy, terms and cookie-consent surfaces
- multi-locale content architecture
On-chain data & observability
You cannot operate what you cannot see. Structured logging with rotation and retention, product analytics, cost and slippage attribution, health checks and alert routing — designed in from the start rather than bolted on after the first incident.
- structured logs + rotation + retention
- analytics + event pipelines
- health checks, alerting, incident routing
- automated log analysis for silent failures
Web platforms & content systems
Fast, statically rendered, accessible sites and dashboards built on a component-and-content architecture — including the open CMS this site itself runs on — shipped through automated pipelines onto global CDNs with real domains and real analytics.
- static rendering + SEO-correct routing
- WCAG 2.2 AA as a build requirement
- CI/CD to CDN, custom domains, analytics
- content editable without touching code
Engagements usually start with one hard problem — an execution path that keeps bleeding to slippage, a model that needs guardrails before it can be trusted with anything real, a protocol integration nobody wants to own. That is the right place to start.
How an engagement runs
Narrow first, then hardened, then yours.
We do not open with a six-month roadmap. We open with the single riskiest part of the problem, prove it works against reality, and only then build outward — because the parts that look hard on a whiteboard are rarely the parts that actually hurt.
01 scope
Find the real risk
Read the existing system, the constraints and the failure history. Name the one thing most likely to sink the project, and start there.
02 prove
Build the thin slice
A narrow end-to-end path against the real protocol, real data and real latency — never a mock. If the idea is wrong, it should be wrong cheaply.
03 harden
Add the rails
Limits, retries, failover, backoffs, kill switches and tests over every path that can move value. This is where most of the engineering actually lives.
04 instrument
Make it legible
Structured logs, telemetry, cost attribution and alerting, so the system can be operated by someone who did not write it.
05 operate
Run it in anger
Deploy, watch it under real conditions, and fix what production teaches you — with a regression test for every incident.
06 hand over
Leave it maintainable
Your repository, your keys, your infrastructure, documented in the same file the code is written against. No lock-in, no black box.
We are comfortable being the team that owns a subsystem long term, and equally comfortable handing it over and walking away. Both are stated up front — the architecture is the same either way, because a system only one team can operate was never finished.
How we build
Non-negotiables, on every engagement.
These are not aspirations we bring up at the end of a project. They are the working defaults, and they are the reason our own system can be left running unattended against real capital.
Tests around anything that moves value
Decision logic is separated from I/O so it can be tested as pure functions. New behaviour ships with tests; bug fixes ship with the regression test that would have caught the bug. A change that passes without touching a test is treated as a red flag, not a win.
Deterministic limits around every model
An AI recommendation is an input, never an authority. Whatever the model returns is validated, clamped against explicit limits, and rejected outright if it falls outside them — so the worst case is a missed opportunity rather than an unbounded loss.
Secrets and blast radius are designed, not patched
Keys live in the environment, never in the repository. Privileges are split so that any single compromised component is bounded by what it can reach — and we say plainly which risks a given architecture accepts rather than implying there are none.
Configuration over redeployment
Thresholds, limits, rosters and content live in configuration and content files with sane defaults, so tuning a live system does not mean shipping code. Operators change behaviour; engineers change capability.
Accessibility is a build requirement
Every interface we ship targets WCAG 2.2 Level AA — real contrast ratios, visible focus states, keyboard paths, reduced-motion support. It is checked as part of the build, not left for a remediation project later.
Documentation that lives with the code
Architecture notes, gotchas and operating instructions live in the repository next to what they describe, so they are updated in the same commit as the change. Documentation stored somewhere else is documentation that will be wrong.
Stack
What we reach for.
Chosen for operability rather than novelty — every one of these is running in production on something we are personally on the hook for.
Chain
- Solana
- SPL + Token-2022
- Jupiter
- Meteora
- RPC failover
- EVM chains
Intelligence
- Claude API
- Structured advisors
- Schema validation
- Model fallback
- Per-call cost tracking
- Agent orchestration
Runtime
- Node 20 · ES modules
- Pure-function cores
- Atomic state files
- Long-running daemons
- Drain-safe restarts
- AWS
Data & telemetry
- Market data aggregation
- Structured logging
- PostHog
- Cost + slippage attribution
- Alert routing
Web
- Vue 3
- Vite
- Static site generation
- Headless content architecture
- CDN + CI/CD
We are not religious about any of it. If your team already runs a different stack well, the right move is usually to build inside it rather than hand you a second one to maintain.
Next step
Bring us the part that scares you.
The best first conversation is about the specific thing that keeps breaking, or the thing nobody on the team wants to own. Tell us what it is and we'll tell you honestly whether we're the right people for it.
Typically a reply within two business days.