Milestone 5: Liquidity That Runs Itself
Milestone 5 removes the Skyhook team from the operation of the bridge. In the beta, liquidity depends on bots, servers and wallets run by the team, which is acceptable for a demonstration but fatal for a protocol. This milestone delivers what anyone needs to provide liquidity independently: a liquidity router that matches demand with supply, a published standard and ready-made binary for self-hosted liquidity nodes, and reference libraries for wallets and protocols. It comes last among the build milestones because a standard should describe the system as it was finally built, not as it was first imagined.
Deliverables
Each deliverable removes a different barrier to participation:
- The standard specifies quoting, intents, fills and status reporting precisely enough that two independently written codebases can trade with each other.
- The binary turns running a node into a matter of downloading and operating software rather than writing it, which decides who can take part at scale.
- The reference libraries let wallets and protocols add swaps as a dependency rather than a project, absorbing the complexity integrators shouldn’t have to see.
The router
The liquidity router directs swap demand to suitable supply across the population of self-hosted nodes. It tracks their advertised quotes continuously and matches each request against nodes’ capabilities, such as the assets they support, the sizes they accept and their record of responsiveness. Clients then carry out the routing decision themselves.
The router holds no funds and has no authority over settlement; it only recommends counterparties. That keeps it entirely outside the trust boundary. A malicious or malfunctioning router can recommend badly, but it can’t steal, because execution and verification stay with the transacting parties under the swap lifecycle.
Node economics
Self-hosted nodes have to pay for themselves; otherwise the network would centralize around subsidized operators whatever the protocol says. Node revenue comes from quoted spreads. Costs fall into three categories: access to chain data, compute for building and proving fills, and, for providers selling ETH, the capital tied up in escrow while fills are open; providers selling ZEC lock nothing (Providing Liquidity). The standard keeps requirements modest enough for consumer hardware, with no proving clusters, archival nodes or always-online guarantees beyond responding to quote requests. Profitability at small scale is a design constraint rather than a hope, because it decides whether decentralization survives real costs.
Integration tiers
The integration targets fall into three tiers by effort, each served by its own deliverable:
| Tier | Uses | Effort |
|---|---|---|
| Individual operators | The binary and a funded wallet; listed by the router | Operations only |
| Wallet developers | The reference libraries, to offer swaps in existing interfaces | Integration against documented APIs |
| Protocols, such as Maya Protocol and NEAR Intents | The standard | Conformance work on both sides, repaid at volume |
Progress in one tier never blocks another: an individual can self-host while wallet integrations are still under way, and a protocol can conform while operators scale independently.
Governance of the standard
A standard without a maintenance process freezes when published and drifts away from its implementations within months. The milestone therefore specifies governance along with the technical content: explicit versions, a recorded amendment procedure, backward-compatibility rules that separate additive extensions from breaking changes, and a conformance test suite for each revision. Authority to amend the standard rests with documented rough consensus among implementers, not with its original authors, since a standard controlled by the team would recentralize exactly what the milestone decentralizes.
Non-conformance
In practice some nodes will deviate, through bugs, modified software or malice, and with no central operator to appeal to, the damage has to be contained by existing verification rather than a new enforcement layer. Misquoted fills fail the same acceptance checks as any invalid intent. Unresponsive nodes automatically lose routing share, and clients route around degraded nodes without coordination, so the router’s responsiveness tracking doubles as a reputation system with no identity layer. Sustained non-performance leads to removal from listings by rule, without votes or committees, which keeps the mechanism working at a scale where committees couldn’t convene.
Status
Done
The system to be standardized is already running. A liquidity server serves quotes, builds intents, drives fills and reports status against a live deployment, and an aggregator provides a read-only routing surface over registered providers. Both bespoke and standing flows settle through this stack, with a driver reconciling fills from preparation through to claim. Because the standard will describe running software, it can demand conformance rather than speculation, and writing it is largely editorial work over proven operations.
Remaining
The formal artifacts remain to be produced: the published standard, the packaged self-hosting binary, the reference libraries for wallets and protocols, and the third-party integration demonstrations. No external party integrates against the system yet. Acceptance requires both publication and a demonstrated integration, using the Zkool2 wallet fork from Milestone 4.