Thanks everyone. Rather than re-post the whole proposal, here is what changed since the 2 August version and who raised it. The full updated text is in the repo at GitHub - 1delta-DAO/1delta-X · GitHub, and the first on-chain submission is T1 only - $3,000 released on approval, reserved for the audit. M1–M4 each go up as a separate on-chain proposal when the milestone is reached.
What changed
Change
Raised by
Tranches restructured: M4 is now $10,000 (28.6%) and releases only after an impact review against the Value Commitment Plan, 12 months post-funding. $1,000 came off M1 and M3, $2,000 off M2
Incident-response procedure for the immutable contracts; allowances default to time-bounded; pre-audit approvals capped in the interface (~1,000 USDRIF per user)
Market orders can also run as a priority auction, alongside the Dutch auction described in the original post. The user signs a floor price and a better price above it; fillers compete by bidding gas price within the next block, and the highest bid wins, with the bid paid to the user as price improvement. On Rootstock’s ~30-second blocks a time-decaying price can only step once per block, so a Dutch auction either gives away a large slice per step or takes many minutes; a priority auction settles in one block. The contracts support both; no code changed. The user’s guaranteed floor is unchanged.
Solver outreach
We have reached out to a handful of solver teams; two are interested so far. Their condition is the one you would expect: enough order flow to justify committing inventory. That is what M1 and the M2 independent-volume gate are there to show, and why the SDK now ships in M1. As said earlier, we will not name them; independent fills are verifiable from the filler address on-chain.
Hello team , i really like the idea of making it permissionless, but I have a security question .
Especially in these times, where attackers are using AI to find exploits faster and faster:
How secure is the protocol against a malicious solver or a vulnerability in the settlement contract?
I understand that the user defines their limits and the contract enforces them, but I’d like to better understand what happens if someone tries to attack the system.
Are there audits / formal verification? And which parts of the protocol still rely on trust in 1delta?
For me, permissionless is great, but permissionless + security is the key.
The USDRIF exit problem is real and measurable — thin, one-sided pools aren’t a narrative issue, they’re a product failure for anyone who actually needs to leave the asset.
Intents fit that better than “hope the AMM rebalances.” Signing an outcome, letting solvers compete, and allowing partial fills is the right shape for size in a shallow market. Permissionless solving guaranteed by immutable contracts (not by an operator’s policy) is also the right ambition for Rootstock if we want infrastructure, not another curated venue.
I’d lean support conditional on three hard filters:
Independent solver volume before most of the grant unlocks. A live third-party solver at M2 is necessary but not sufficient — meaningful independent fill volume should gate capital, otherwise we mostly fund a self-filled path plus an audit line.
Pre-audit blast radius. M1 with real users on unaudited immutable code needs explicit per-fill/total caps, time-bounded allowances, a loud unaudited banner, and a one-click revoke path. No TVL at rest helps; it doesn’t remove allowance risk.
Honest RIF accounting. Redemption-backed sells are RIF supply into a thin on-chain exit; mint is demand. Split redemption vs mint in monthly reports so we don’t sell one-way flow as “RIF economy enablement.”
One more structural point: open settlement ≠ open orderflow if indexing stays on a single backend. Fine to centralize in M1/M2 for speed — but a concrete path to multi-operator order books should be on the record, not a vague “research Waku later.”
If those hold, this is a serious attempt to fix USDRIF usability. If they slip, we’re paying for a polished demo with weak market validation.
We have added comprehensive unit tests to the settlement contract (github.com/1delta-DAO/1delta-X) that validate that all such attacks are mitigated (e.g., creating malicious orders to match, trying reentrancy, creating fake modules, and much much more).
On top of that, we also specifically test against all common solver/aggregator incidents that have happened so far (typically allowance draining via reentrancy), such as Paraswap’s incident and the one that occurred with Matcha Meta.
The code will also undergo an independent formal audit (we specifically picked T1 and M1 to pay for that).
The trust in 1delta is mainly based on us operating the backend. However, the order book backend will also be open-sourced so that anyone can run an instance themselves.
thanks for the feedback. All four points are I think covered in the changes summary in post 21 that might be easy to miss:
Independent volume gates capital: M2 requires ≥$10k settled by solvers we do not operate, M3 ≥$50k and M4 ≥$150k, with M4 also behind the 12-month impact review (per @Curia and @Tane). Before any independent volume is shown, 43% of the grant can be released, not 66%.
Pre-audit blast radius: Approvals capped in the interface at ~1,000 USDRIF per user plus a total cap, both published before the first fill; allowances time-bounded by default; an unaudited-contract banner for all of M1; and a one-click revoke path as step 2 of the incident procedure in [post 3] (per @LEGOSI and @Kath).
RIF accounting: Redemption-side and mint-side volume are reported separately from M1, with mint-side floors of ≥$50k at M3 and ≥$100k at M4. The “RIF Economy” wording was corrected to flow in both directions, not net demand (per @ChronoTrigger).
Order flow: We run the only backend in M1 and M2, and it is open source, so anyone can run a second book from day one. Multi-operator order books are therefore available immediately; what is not yet is a shared source of truth across them. Waku is the candidate for that: order flow as a stream of immutable messages any operator syncs from. It works; what has to be shown is that it holds at scale at acceptable cost, the usual bottleneck for decentralised storage. We evaluate it after the audit and report the scale and cost result in the M3 Monthly Activity Report, so the decision is on the record rather than deferred.
Appreciate the transparency on the security architecture here. Implementing hard pre-audit caps and explicitly testing against known reentrancy exploits from other aggregators is good defensive engineering. However, from a capital efficiency standpoint, the real test of this grant will be the transition from M2 to M3. Running your own backend to fill M1 and M2 protects users early on. We will be watching the monthly activity reports closely to ensure the independent volume materializes as projected before supporting the final tranches.
Quiero agradecer a @Achthar por abordar mis inquietudes originales con tanta seriedad y rigurosidad técnica. Mi escepticismo inicial respecto a la viabilidad económica de los solvers no era menor; en arquitecturas basadas en intenciones Intents, el incentivo del buscador es el motor que sostiene todo el sistema. Sin márgenes claros debido a los costos de gas y la fragmentación de la liquidez local, el riesgo de acabar con un protocolo fantasma sin competidores reales es sumamente alto.
Sin embargo admito que, los datos empíricos de enrutamiento que el autor ha presentado en sus últimas respuestas cambian el panorama. El desglose matemático detallado, demuestra cómo las microfinanzas de los DEXs locales interactúan con el peg de USDRIF, soluciona mis dudas con mediciones tangibles en lugar de promesas abstractas. Se ve serio. Se ve bien.
Esta precisión me da la confianza de que los solvers de código abierto tienen incentivos económicos reales para competir de manera rentable en la red. Considero también que mis dudas han sido resueltas mediante evidencia sólida y, por ende, valido plenamente esta propuesta para su avance hacia la votación.
The gasless USDT0 swap experience is particularly interesting for making DeFi more accessible on Rootstock.
As a Rootstock Ambassador in Japan, I often focus on helping new users understand how these tools work.
Does the team plan to publish a simple explanation of how gasless swaps are executed, including who covers the transaction fees and what users should know about potential risks?
I think this would be valuable for onboarding new users.
To summarize, we use erc20Permit (gasless approvals) and the intents together - this means the solver pays for both the approval and the execution gas - this is reflected in the quote .
In many cases, we are even better than the aggregator, even if the gas is included.
This example shows that we can quote better and the ~$0.60 in gas are included in it, of which about ~$0.1 comes from the premit for USDT0.
Congrats on getting the beta live, @Achthar, and good to see the unaudited-contract notice in the app.
Before further promotion, including the raffle and the official announcement, could you confirm how the per-user cap of about 1,000 USDRIF and the total cap you committed to are enforced, and post both figures here?
