mirror of
https://github.com/luxfi/dex.git
synced 2026-09-24 00:26:31 +00:00
main
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  zeekayandHanzo Dev
|
406ee2695a |
dexprotocol: move once, trade many — D owns what it trades
C and D each own value while it is on that chain, and a unit is spendable on exactly one of them at a time: C --Export--> C_TO_D --Import--> D --Export--> D_TO_C --Import--> C Those four transitions and no others. Never C to D directly, which would mean a moment where value is in both places or neither. The consequence is the point. Once imported, D is not matching against hypothetical C collateral — it has real balances, and every order, match and trade is a local movement. A million trades cost zero boundary crossings. That is what makes D an exchange ledger rather than a remote matching oracle attached to C. So the atomic rail is narrowed to one job: move ownership exactly once. It knows nothing about orders, executions, trades or settlement. The per-trade cross-chain certificate, the C-parent reservation and the accept-or-release round trip stay only for the V4 adapter, where a contract genuinely demands synchronous C composability. Import consumes and credits in one operation. Splitting them either destroys value or lets a retry, a reorg, a racing relayer or a restart import the same object twice, which is a double-spend of real money. Refusal is loud rather than silent — a caller that imported twice has a bug worth seeing. Export draws only on available balance, so value committed to an open order cannot also leave the chain. A claim names its beneficiary, which is what makes import safely permissionless: delivering one can only credit the account it already names. Co-location buys latency, never correctness. Execution now carries MarketVersion and the exact token amounts D resolved, so C verifies amounts rather than recomputing lots from whatever the market says now — recomputing would replay a block to a different result after a market update. Price is gone; it was Output over Input stated twice inside a signed struct. Partial execution is bounded by cross-multiplication, executionOutput * orderInput >= executionInput * orderMinOutput, so there is no division, no rounding convention, and the rule composes: if every slice satisfies it, so does their sum. 60 tests. Conservation asserted after all 600 operations of a random run: imported 4143, exported 2576, D owns 1567. Co-authored-by: Hanzo Dev <[email protected]> |
||
|
zeekayandHanzo Dev
|
be195f4a8d |
dexprotocol: the Order is the authorization, and it is portable
The trader signs an Order and nothing moves. D's book matches it and
certifies an Execution; an operator carries Order + Execution + proof to
the C reactor. Only an accepted C block turns that Execution into a Trade.
CParent leaves the Order and stays on the Execution. An order is a
long-lived authorization; a reservation is scoped to one C opportunity.
Braiding them made the trader responsible for guessing which block their
order would match under, and killed the property the book depends on: an
unmatched order stays live, and one whose Execution was released can be
matched again.
Three things this shape forces, each a bug it makes unwritable:
Nonces are UNORDERED, a bitmap position rather than a counter. D matches
by price-time priority across every trader, so one trader's orders settle
out of signing order as a matter of course. A sequential nonce rejects
the low one arriving second and then blocks that trader permanently,
because the expected value can never advance past an order that may never
match.
The commitment binds NetworkID, CChainID and the reactor address, inside
the hash rather than beside it. 0x9999 runs on every EVM sharing the one
D venue; an unbound signature is one an operator replays against each in
turn, and the trader pays on all of them for the single trade they
authorized. Bound, that replay is not detected — it is unrepresentable.
Input and MinOutput are in token base units and 32 bytes wide, not the
book's lots in a uint64. They are different quantities describing the
same trade, and one type for both would let a lot count be added to a wei
balance. uint64 also caps an 18-decimal token near 18 units.
VerifiedOrder follows VerifiedExecution: unexported interface method as
the sentinel, since unexported fields alone leave Order{} constructible
anywhere. Verification stays a pure question — it does not consume the
nonce, or merely inspecting an order would burn the trader's position.
The deadline is read against the block being built, never a clock.
49 tests, up from 25.
Co-authored-by: Hanzo Dev <[email protected]>
|
||
|
zeekayandHanzo Dev
|
438ad8eb9a |
dexprotocol: CParent means accepted C block, and non-inclusion is a real proof
THE INVARIANT
An Execution may be reserved only against an accepted C parent. The unique
accepted child of that parent permanently decides the Execution: membership
means Trade; non-membership means Release. Neither C nor D reads the other
chain's live state during consensus execution.
CPARENT ACCEPTED-ONLY
Acceptance is the finality boundary, so an accepted P is guaranteed exactly one
accepted child, and that child decides every execution reserved against P. This
removes the abandoned-parent case entirely rather than handling it: there is no
proposed parent to abandon. It also collapses two questions — "did P win?" and
"which child of P won?" — into one.
AcceptedBlock is now a struct with unexported fields, produced only by
VerifyAcceptedBlock. Unexported fields alone still leave AcceptedBlock{}
constructible from outside, so a `verified` sentinel closes that hole and every
transition requires it. Symmetric with VerifiedExecution.
Never use local C state as the proof. Even co-located, different D validators
observe C advancement at different instants, so `localC.LastAccepted()` is not a
function of the block being executed. The local C VM is delivery; the
authenticated statement is consensus input — the same rule already proven in the
other direction.
THREE RULES, NO CLOCKS
Accepted(P) permits Reserve(E), E.CParent == P
Accepted(Q), Q.Parent==P, E in Q.ExecRoot permits Settle(E) -> Trade
Accepted(Q), Q.Parent==P, E not in root permits Release(E)
NON-INCLUSION IS FIRST-CLASS
Release is half the protocol, not a fallback, and it is the half that returns a
trader's liquidity. So ExecRoot is a sparse Merkle commitment over the 256-bit
ExecID keyspace where absence has the SAME proof shape as presence: the path to
the key, terminating in the empty leaf. One verifier, one code path, one bit of
difference. Leaf and node domains are separated against second-preimage
substitution, and the empty leaf is a distinct constant so absence cannot be
forged. Proofs carry a bitmap and omit empty siblings, so size tracks the
executions actually in the block, not the depth.
A useless reservation is still resolvable: if D reserves against P only after C
accepted Q, anyone can deliver Accepted(Q) plus non-inclusion and release it.
Correctness does not depend on D winning that race.
Also removes the last references to a flag day, which was never authorized —
0x9999 activated 2025-12-25 and settle_module is AlwaysOn. The wire-compatibility
test keeps its value and loses the dead concept from its name and prose.
24 tests passing in dexprotocol, dchain suite green.
Co-authored-by: Hanzo Dev <[email protected]>
|
||
|
zeekayandHanzo Dev
|
c935e4d228 |
dexprotocol: the cross-chain exchange vocabulary, with the bug class unwritable
The C transaction contains an Order. D matches it and certifies an Execution — price and quantity guaranteed and reserved. The C block carries that Execution. EVM execution verifies it and returns the resulting BalanceDelta. When the child of the Execution's C parent is accepted, D settles it into a Trade if that child used it, or Releases the reservation if it did not. This is the consensus-side half: the certified object, its canonical encoding and domain-separated commitment, and the lifecycle. WHY IT IS SHAPED THIS WAY C never queries D's live state during EVM execution — that would fork C on the first swap, since validators sit at different D heights. Instead D's statement rides in the block and C verifies it. On replay D can be dead, the GPU gone, D a billion blocks ahead; C has parent state, transactions, the statement, and the certificate. That is the entire input set. Move-typed storage, not a status field. ReservedExecution, Trade and Released are distinct types under distinct key prefixes, and a transition MOVES the object. Settle(Trade) and Release(Trade) do not compile — there is no reserved execution left to hand them. This is aimed squarely at the live defect where the intent record is written back only inside the same-asset refund branch, so the ordinary proceeds outcome leaves it Open with its full principal and the deadline reclaim later refunds money already spent out of other traders' pooled reserve. That is a field someone forgot to set on one code path; here there is no field to forget. An unauthenticated execution cannot enter the lifecycle: VerifiedExecution is an interface with an unexported method, so only VerifyExecution can produce one, and Reserve takes nothing else. AcceptedBlock is the same shape, so a settle or release can never be driven by a clock or a bare block id. The reservation is keyed by CChain + CParent + ExecID — the parent OPPORTUNITY, never a candidate block — so competing candidates all name one reservation and none of them moves it. FIX Latest externally, small internal vocabulary. ExecType (the event) and OrdStatus (the resulting state) exist on the wire and are kept distinct per FIX; they are never the internal source of truth. There is deliberately NO FIX state for the provisional reservation — it is internal consensus machinery, and a Trade is published only after C acceptance, which is what keeps the explorer's CLOB honest. 15 tests, all passing: encoding injectivity over every field, domain separation, verifier-supplied parent binding, terminal exclusivity, replay refusal. Co-authored-by: Hanzo Dev <[email protected]> |