Blockchain systems beyond
the smart contract.
The contract is one layer of eight. Most of what decides whether a blockchain system survives production lives in the indexing, the risk model and the reconciliation nobody demos.
Eight layers, not one.
A reorg that corrupts indexed balances, an oracle that goes stale mid-move, a retry that submits twice. None of those are contract bugs.
- 01
Smart contracts
Audited, role-gated, upgrade-aware on-chain logic with property tests.
- Solidity
- Foundry
- Slither
- 02
Protocols
The economic design around the contract: incentives, parameters, failure behaviour.
- Mechanism design
- Simulation
- 03
Indexing
Reorg-safe cursors and deterministic rollback, so history stays correct.
- Rust
- ClickHouse
- ABI decoding
- 04
Data
Entity resolution, flow aggregation and analytics over raw chain events.
- Columnar store
- Graph store
- 05
APIs
Idempotent mutations, request signing and typed clients over it all.
- Node.js
- REST
- Webhooks
- 06
Risk
Collateral health, oracle staleness and concentration limits, evaluated continuously.
- Risk engine
- Policy as config
- 07
Reconciliation
A double-entry ledger that is authoritative, with breaks raised as exceptions.
- PostgreSQL
- Double-entry
- 08
Applications
The product a person actually uses, with every failure state designed.
- Next.js
- React
- TypeScript
What we build on-chain.
Each of these is a different system with different failure modes, not a variation of one template.
Also in scope
DEX
Order books, AMMs and routing with real depth.
Token
Supply, vesting and transfer rules that hold up.
NFT
Collections, ownership and marketplace mechanics.
Wallet
Key management, signing and recovery flows.
Launchpad
Issuance, allocation and vesting under policy.
DAO
Proposals, voting, timelocks and execution.
Where blockchain systems actually fail.
These are the problems we design for first, because retrofitting them is expensive.
Reorgs corrupt indexed state
Indexers write against a confirmed cursor with a deterministic rollback, so a reorg is a handled event with an affected range — not silent data loss.
Oracle failure is a solvency event
Feeds are checked for deviation and staleness before entering a risk model. On breach the engine holds last-known-good and blocks new leverage.
Retries submit transactions twice
Every mutation carries an idempotency key and moves through an explicit state machine with replacement and cancellation paths.
Balances read from the chain are already wrong
A double-entry ledger with enforced invariants is authoritative. Chain state is an input to it, never the number a user sees.
Eligibility changes but contracts do not
Transfer restrictions call a registry at transfer time, so a lapsed accreditation blocks a transfer without redeploying anything.
Building something on-chain?
Bring us the protocol, the product or the problem. We’ll help define the architecture and the path to production.