How a volume engine works
The six components every volume engine contains, the data that crosses each boundary, and why the interesting engineering sits in the queue rather than the swap call.
Open the noteArchitecture: components, contracts and boundaries
Architecture is the part of the system you cannot refactor cheaply. A retry policy can be rewritten in an afternoon; a decision to let the builder reach into the wallet pool directly will still be costing you three months later, because every failure now has two possible owners and no clear log.
The notes in this section describe the parts a volume engine contains, what crosses each boundary, and the specific trouble that follows when a responsibility ends up in the wrong component. They are written as component sheets rather than tutorials, because the useful thing to copy is the interface, not the implementation.
- Components
- Planner, fleet, scheduler, builder, sender, ledger
- Boundary rule
- One owner per failure mode
- State
- Fleet holds accounts, ledger holds truth
- Trade-off
- Fewer parts is simpler, more parts is testable
3 notes in this section
The parts a volume engine is assembled from, the interface each one exposes to its neighbours, and what breaks when a boundary is drawn in the wrong place.
Wallet fleet design
Treating many signing accounts as one addressable resource: derivation, roles, balance floors, lease semantics and the ledger that keeps the fleet reconcilable.
Open the noteScheduling and pacing
Turning a budget into a stream of timed intents: token buckets, jitter, session curves, and why a fixed interval is the one shape a scheduler should never emit.
Open the noteWhat this section deliberately leaves out
These notes stop at the interface. They do not specify a language, a framework, a database or a hosting shape, because those choices barely change the failure modes and they date faster than anything else in a design. They also do not describe how any particular product is built. Where a hosted engine appears in an example, it is described by the behaviour a user can see from the outside.
Pipeline Build, sign, send, confirm What happens to a single swap between the moment a scheduler emits it and the moment a validator finalises it, stage by stage, with the failure mode of each stage. Reliability Failure, retry, scale Retries that do not double-spend, backpressure that protects an endpoint instead of hammering it, metrics that expose the truth, and a growth path that does not break on the way up. Engine notes The full index Every note the desk has published, listed with the component it describes and the section it belongs to.