Hi LEGOSI,
Thanks for the feedback.
1. On the solver economic model
It is correct that we asserted the spread exists without showing it. Everything below is read from mainnet contracts and live exchange books (quotes come from the Uniswap v3 QuoterV2 0xb51727c9…), which returns executable output including tick-crossing slippage rather than a spot-price estimate.
A small correction: We stated the RIF on Chain redemption fee as 0.25%. Read on-chain today, tpMintFees and tpRedeemFees for USDRIF both return 0.20%. Our Appendix A worked examples decoded 0.25% and are correct for those July transactions: the parameter was lowered since. There is also a fee-token discount: fees paid in MOC are reduced by a third, to ~0.133%. We’ll correct the proposal.
What the data shows
Our expectation was that there would not be a single best execution path. The analysis confirms that: the optimal route depends on both trade size and direction. That’s exactly where an intent-based approach adds value, because it allows the solver to choose the best route at execution time instead of forcing users to make that decision themselves.
USDRIF received per dollar, acquiring USDRIF:
| $ input | Buy on DEX | Mint from RIF (oracle) | Best |
|---|---|---|---|
| $10,000 | 10,018 | 9,986 | buy |
| $50,000 | 49,828 | 49,929 | mint |
| $100,000 | 66,466 | 99,859 | mint |
Proceeds from selling RIF:
| $ of RIF | Sell on DEX | Sell on CEX | Mint USDRIF → sell | Best |
|---|---|---|---|---|
| $1,000 | $944 | $1,000 | $996 | CEX |
| $10,000 | $4,706 | $9,973 | $9,953 | CEX |
| $25,000 | $5,269 | $24,859 | $24,876 | mint |
| $100,000 | $5,531 | $98,192 | $99,336 | mint |
Two things stand out. A $100k DEX purchase of USDRIF returns 66,466 USDRIF, while minting returns 99,859: around a third of the value is lost to slippage on the DEX. Conversely, above roughly $25k, routing RIF through a USDRIF mint outperforms the combined Binance/MEXC/Gate order books because it converts at the oracle price without slippage before exiting through the deeper side of the market.
Selling USDRIF is the one direction where the DEX is currently competitive (0.9948 at $100k), while redemption is more efficient below roughly $25k. The picture is therefore consistent across all four routes: protocol-based execution tends to dominate at larger trade sizes, market execution often wins for smaller trades, and the crossover point moves over time. A solver’s role is simply to determine the best route at the moment the order arrives, allowing users to express a single intent without having to make that decision themselves.
Does the margin narrow? Yes, but the opportunity changes sides
Rather than modelling a compression scenario, we measured the market three days apart:
| 2 August | 5 August | |
|---|---|---|
| Oracle vs market price of RIF | +0.91% | −0.20% |
| Solver margin, redemption route | ~89 bps | ~0 bps |
The redemption spread disappeared over those three days, while the USDRIF/USDT0 pool inverted from 153,986 USDRIF against $37k of USDT0 to 66,688 USDRIF against $124k, with total liquidity remaining roughly constant.
That closed one arbitrage opportunity but opened the other. Redemption arbitrage supports the peg from below; mint arbitrage caps it from above. Today the profitable side is minting rather than redemption. The direction changed, not the business.
If neither route is profitable, solvers fill inventory-free with DEX aggregation rather than fill at a loss with redemption, so there is no user forced into a worse execution. Orders either rest or continue decaying until a solver can profitably execute them - with or without the redemption route.
Why this does not reduce to a single route
The naive version of the cycle does currently not work. A solver that redeems USDRIF and immediately dumps the resulting RIF into the RIF/USDT0 pool gets a bad price at every size: $100k of RIF returns about $5,531 there. That pool is thin and cannot absorb size.
However, the inverted route - converting RIF back into stablecoin on-chain at size does work: through the protocol rather than through the RIF pool:
| Converting $100k of RIF to stablecoin | Proceeds |
|---|---|
| Sell into the RIF/USDT0 pool | $5,531 |
| Combined Binance / MEXC / Gate book | $98,192 |
| Mint USDRIF from the RIF, then sell the USDRIF | $99,336 |
The protocol route is roughly 18× better than the naive on-chain path and beats the combined CEX book by about 1.17%, because it converts at oracle price with no slippage and then exits through the deep side of the market instead of the thin one. So RIF recycling is not inherently an off-chain problem. It is a routing problem, and it has an on-chain answer.
This is also why the design is symmetric. The same primitive solves in both directions: redemption-backed fills serve USDRIF sellers, mint-backed fills serve RIF sellers and USDRIF buyers. A solver running both sides is not carrying one-way inventory risk and is intermediating two flows that partially offset, and the residual is what needs an external route at all. Two users on opposite sides of the same asset can be matched against each other with no external venue involved.
The model rests on a set of interchangeable routes like these:
- DEX aggregation across the venues on Rootstock,
- protocol mint and redemption at oracle price,
- off-chain venues where they are genuinely better
The solver picks per order. Route availability rotates, as the pool inversion above shows. Having several, with a slippage-free one always present, is what makes that viable.
What remains is a risk constraint due to the cycling through CEXs carrying RIF price risk (RIF had larger price movements in the recent weeks). This however can be hedged via e.g. Binance Futures.
2. On KPIs that depend on third parties
That part is deliberate: those KPIs are the experiment, not a forecast. Two things are unknown: whether there is real demand for better USDRIF&RIF swaps, and whether independent solvers will show up for a market this size. We would rather be measured on both than be paid for providing infra that nobody uses.
The second depends on the first. Solvers choose venues on one criterion above all others: order flow. Nobody runs infrastructure against an empty book, and no amount of documentation substitutes for volume worth competing for. That is why the milestones run in the order they do: we operate the first solver so the market works on day one, the tooling goes out open source at M2, and the independent-solver floors sit at M3 and M4 rather than at launch, sized to when a third party could realistically be running one at all. Proving the system sources order flow is the recruitment strategy.
If adoption is slower than expected, the milestone does not pay out (or pay out later); that is what gating is for. We keep operating and capitalising our own solver past grant close, keep the SDK and dashboard maintained and open, and report the shortfall and the corrective action in the Monthly Activity Report that catches it.
3. On immutability and incident response
This is an important point.
One key fact: the protocol holds no funds at rest. There is no TVL in the settlement contract. Value moves through a fill atomically and settles to user and solver in the same transaction. There are no balances to drain as user exposure is bounded strictly by outstanding token allowances on the permission layer, and every holder can revoke their own allowance unilaterally at any time.
Our procedure if a vulnerability is found post-deployment:
- Stop new exposure immediately. We control the initial order backend and frontend even though we do not control the contracts. Order intake stops, the interface goes down, no new orders reach solvers.
- Publish a revocation notice with a one-click revoke path. Because exposure equals allowance, revocation is a complete fix per user, and it does not require our cooperation to work.
- Disclose publicly within 24 hours: forum and channels: with the affected contract, the nature of the issue, and the user action required.
- Deploy corrected contracts at a new address and migrate. For an immutable system, redeployment is the upgrade path; the old contracts are abandoned rather than patched.
- Publish a post-mortem, with the fix re-reviewed by the auditor before the interface points at the new deployment.
To reduce risk directly: the interface will default to time-bounded allowances rather than unlimited approvals, so exposure decays automatically for inactive users; and during the pre-audit M1 window, caps and access are enforced in the interface rather than in contract logic: precisely because limits meant to bound risk from unreviewed code must not depend on that code being correct.
We would rather have this constraint than an admin key, which would undermine the property this proposal is actually about.
4. On the metrics one would use
We agree with all four and can adopt them into the Monthly Activity Report and the public dashboard from M3:
- Execution price versus alternatives: for every fill, the realised price against what the same size would have received through the standard route at that block.
- Average time to execution: signature to settlement, per order type.
- Independent solver count over time, not just the M2 pass/fail.
- Slippage: with one clarification worth making.
On slippage specifically: the intent model addresses it differently from an AMM, and this is central to why it fits a thin market. In an AMM the user’s own order walks the curve, so the loss grows with size and thinness: precisely USDRIF’s problem, and precisely what the 66,466-versus-99,859 figure above measures. Under a Dutch auction the order opens at a price favourable to the user and decays until a solver takes it, so the user cannot suffer instant execution slippage; the worst case is a longer wait as the price decays, and the floor is the minimum the user signed. The solver absorbs execution risk, and competition means it is absorbed at the best price the market will bear. 1inch documented this mechanism in A deep dive into 1inch Fusion; ours is the same auction shape, with no whitelist on who may compete.
5. On the period after the grant
The mechanism that makes this sustainable is the one in 1): solving is a business with a real, two-sided, measurable margin, not an activity that needs subsidising. Nobody has to be paid to run a solver: they have to be allowed to, which costs nothing and is guaranteed by the contracts rather than by our policy.
Concretely, past grant close: we aim to keep operating our own solvers (with and/or without inventory), we keep the SDK, reference solver and dashboard maintained and open, and the contracts keep running with or without us: no admin, no expiry, no dependency on our infrastructure. Our TVL target is measured 12 months post-funding, deliberately beyond the grant period.