Back every payout
Keep enough collateral to pay the market’s largest possible liability.
dClutch development history22–25 August 2026
Architecture notes
How dClutch changed.
Early builds helped define the protocol’s payout rules, account structure and execution model.
This note covers the first two implementations and the design proposed for the third in August 2026.
01Explore
The first implementation
Build the market’s full lifecycle.
The first Dragon’s Clutch brought together claims, trading, clearing, liquidity, resolution and account closure.
It used roughly fifty protocol accounts and a 51-action namespace. Connecting the operations exposed several requirements: collateral must remain available for payouts; fees and operating funds need separate accounting; source failure needs a defined outcome; and closed accounts must not allow an old transaction to run again.
The account structure also became too complicated. Separate steps in the implementation had become separate accounts, even when they stored parts of the same economic fact.
Store each fact once
Give each balance, permission and replay counter one authoritative record.
02Simplify
The second implementation
Keep the market core small.
The new repository separated universal market rules from optional trading and liquidity features.
Direct trading, batch clearing, liquidity and transferable claims became capabilities that a market could select. The product definition owned the complete set of outcomes, including source failure. Collateral, fees, rent and recovery funding had distinct purposes and balances.
Compiling separate code for each product width made the combined program too large. Much of the growth came from repeated versions of the same operations.
August development buildIntegrated Rust program
10.93 MBWith Structured reachable through the public entrypoint.
Specializing General, Dealer, Structured, Bearer and Position operations for widths 2 through 16 duplicated substantial machine code.
03Share
The proposed successor
Share the execution code.
The next design put variable rules in data that a compact interpreter could execute.
Typed schemas and transition programs would describe account layouts and state changes. Solana adapters would handle signatures, account memory, token transfers and calls to other programs.
The same definitions could supply transaction builders, browser bindings, documentation and test cases. The early three-program slice executed a signed Direct fill with 107,752 bytes of combined program code.
Definitions
Rules and layouts
Typed records, transition instructions and exact payout arithmetic.
Execution
Shared interpreter
Reusable execution code with Solana account and token adapters.
What carried forward
Payout rules.
Simpler execution.
Each version kept the collateral and lifecycle requirements while changing how the code implemented them.
On 25 August, dClutch’s history was added beneath Dragon’s Clutch as a subtree. The earlier implementations remain available in the repository history.