why perfect and not good
A trading model is usually evaluated by its results. Results depend on luck, on the market, and on what the model happened to be given. None of that can be verified at the moment a trade is placed. What can be verified is whether the trade is the best possible one under a stated objective and stated constraints, because for a concave objective that question has a certificate, and a certificate can be checked by a program that has no opinion.
This flips the usual arrangement. The model is not the authority. It is a proposer. The program is the authority, and its only test is a residual that is either zero or not. A model that is clever but inexact will be rejected every time; a model that is dull but exact will be accepted every time. The site records both.
The objective is deliberately simple. The program maximises the sum of the logarithms of its reserve and its inventory after the trade. There is no forecast in it. There is no signal. It encodes a single stance: hold the two sides in balanced proportion and let the curve's own cost function decide how far to move toward that balance each time the market moves away from it.
solving the problem
The feasible set is an interval, so the solve has two cases. Either the unconstrained maximiser of U lies inside the interval, in which case every multiplier is zero and stationarity reads U′(x*) = 0, or it lies outside, in which case x* is the nearer edge, the constraint defining that edge carries a positive multiplier, and the other two are zero.
In the interior case the prover solves U′(x) = 0 by bisection in Q64.64, which converges in at most 128 steps because the derivative is monotone decreasing on the interval. In the edge case the multiplier is read off from stationarity: λ = U′(x*) / g′(x*) for the active constraint. The program does not perform the solve. It only checks.
| case | x* | λ |
|---|---|---|
| interior | root of U′(x) = 0 | all zero |
| reserve edge | x with c(x) = (3/4) · R | λ₁ = U′(x*) / c′(x*), others zero |
| impact edge, buy | x with p(x) = (21/20) · p₀ | λ₂ = U′(x*) / g₂′(x*), others zero |
| impact edge, sell | x with p(x) = (19/20) · p₀ | λ₂ as above |
| inventory edge | x = −I | λ₃ = −U′(x*), others zero |
live solve
This table is computed in the browser from the live state using the same fixed point arithmetic the program uses. It is a readout, not a tool. It shows the objective across the feasible interval so the location of the optimum can be seen, and it marks the certified point when one exists.
| x (tokens) | c(x) (sol) | U(x) | g₁ | g₂ | g₃ | feasible |
|---|---|---|---|---|---|---|
fixed point arithmetic
Every quantity in the check is a Q64.64 number: an unsigned 128 bit integer whose low 64 bits are the fraction. Multiplication is a 256 bit product shifted right by 64; division is a 256 bit left shift by 64 then an integer division. The logarithm is computed from the identity below with a fixed number of terms, which makes it deterministic across machines.
Because the series is fixed, two parties computing the same inputs produce the same bits. That is what lets the program demand a residual of exactly zero rather than a tolerance. The prover and the program are the same arithmetic run twice.
| operation | rule |
|---|---|
| add | u128 addition, overflow aborts |
| mul | (a · b) >> 64 using a 256 bit intermediate |
| div | (a << 64) / b using a 256 bit intermediate, b ≠ 0 |
| ln | 24 term series above, argument reduced to [1, 2) by powers of two first |
| abs | branch on sign, stored as a sign bit beside the magnitude |
| compare | plain integer compare on the u128 |
what the prover is
The prover is a model instance running off chain with a websocket to the curve account and a copy of the program's arithmetic. It holds no keys to the vault. It can only submit certificates. If it goes offline nothing happens: the program simply waits, and anyone else who solves the same problem can submit instead. The mechanism does not depend on the prover being honest, fast, or alive. It depends on the arithmetic.
The prover's output is public. Every submission, accepted or rejected, is written to the record account with its four residual parts, so a reader can see not only what the program did but every time the proposer was wrong and by how much in each condition.
failure table
Each rejection carries its four parts. The table gives what a non zero part means.
| part | non zero means |
|---|---|
| r_stat | The proposed size is not a critical point of the Lagrangian with the given multipliers: the prover solved against stale state or used different arithmetic. |
| r_prim | The proposed size violates at least one constraint: it spends too much, moves price too far, or sells more than held. |
| r_dual | A multiplier is negative, which no valid certificate can contain. |
| r_slack | A multiplier is positive on a constraint that is not tight, or a constraint is tight but carries the wrong multiplier. |