The bidirectional token engine.

6.2The price function

The default price function is the square-root curve:

P = S^0.5

Early buyers get a low price. Increases decelerate as supply grows, so the curve rewards conviction without producing the runaway convexity of a linear or exponential shape. It is continuous and deterministic: the same supply always yields the same price, computed on-chain, with no oracle in the loop.

The exponent is not sacred. It is the first parameter we tune per asset — a curve for a fractionalised building behaves differently from a curve for a royalty stream, and both differ from a curve for a commodity warehouse receipt.

6.3The reserve function

The reserve R — the base asset actually held by the protocol — is the area under the price curve:

R = ∫₀ˢ x^0.5 dx = (2/3) · S^1.5 ≈ 0.666667 · S^1.5

This is the entire trick, and it is worth stating plainly: the reserve is not a number chosen by a treasurer. It is the integral of the function used to price every purchase. Whatever was paid in, along the curve, is exactly what is owed back out along the same curve.

6.4Invariant pricing

When supply moves from S to S + ΔS and a buyer deposits ΔR, the system holds the invariant:

S_new = ( S^1.5 · (R + ΔR) / R )^(2/3)R_new = R · (S + ΔS)^1.5 / S^1.5

These run on-chain on every transaction, so the invariant holds regardless of the order in which trades arrive or the size of any one of them. There is no sequencing assumption to violate, and no state in which a large trade leaves the reserve short.

6.5The solvency theorem

The proof sketch is the reserve function itself. If the reserve is by construction the definite integral of the price function over the circulating supply, then redeeming all S tokens back down the same curve returns exactly R. Not approximately. Exactly. A bank run is not a failure mode of this design; it is just every holder walking down the curve they walked up.

6.6The untouchable reserve

There is no instruction that can withdraw the base asset from the reserve except a holder selling — and therefore burning — their tokens. Any administrative "transfer reserves" path is removed from the program before deployment, and its absence is verifiable by anyone reading the deployed bytecode.

The consequences follow directly:

• The token issuer cannot defraud buyers — there is no function that would let them.
• The platform cannot defraud users, including TokSol. We hold no key that reaches the reserve.
• A compromise of the website or front end cannot reach on-chain funds. There is nothing on the front end that could.
• Solvency is auditable by anyone, in real time, directly from chain state.

6.7Technical stack

Programs are written in Rust using the Anchor framework and deployed on Solana. The rationale is throughput and cost: asset transactions are frequently small and frequently repeated, and a chain whose fees exceed the value of the trade cannot host them.

Throughput

~65,000 TPS

Finality

~400 ms

Cost per transaction

~$0.00025

On-chain state is verifiable on Solana Explorer. Anyone can read the reserve balance and the circulating supply and check the invariant themselves, without asking TokSol or the issuer for anything.

6.8Configurable fees

Fees are set at creation and verifiable on-chain: a platform fee and a configurable issuer fee, applied symmetrically to buys and to sells. They are distributed before the reserve state updates, so the solvency invariant always holds on the net reserve — a fee can never be paid out of the money owed to holders.

Exact parameters are defined per engagement, alongside the curve. We do not publish rates here because there is no single rate to publish.