[2608 Grant Proposal] 1delta Intents — permissionless solving on Rootstock

[Achthar]

1delta Intents — permissionless solving on Rootstock

Project Name & Description

1delta Intents — Bitcoin-native intent settlement, deployed on Rootstock. Users sign what they want; an open set of solvers competes to deliver it. Anyone can solve, from the start, with no whitelist and no inventory of their own. The first market we open this way is USDRIF, which needs it most.

This will be the first intent settlement system that is permissionless all the way down. The smart contracts are immutable and ungoverned, so anyone can solve from the start and nobody can take that away later.

For comparison: CoW Protocol runs a bonded, allowlisted solver set, and 1inch Fusion runs whitelisted resolvers. Both work well, and both mean a new solver has to be admitted before it can compete. Some systems elsewhere do leave filling open. What we have not found is one where that openness is guaranteed by the contracts rather than by the operator’s current policy — ours has no admin who could change it. Rootstock gets that first.

The problem

USDRIF and RIF are easy to mint or buy — and hard to sell. Across USDRIF’s three Uniswap v3 pools, the stablecoin side — the side an exiting holder actually needs — is down to about $99k against a $2.38M supply: enough for roughly 4% of supply to leave before it runs out. One pool is already dead at 14 USDT, and it isn’t an old story. Between our July measurement and this post, sellers pushed ~100k more USDRIF into the main USDT0 pool and took its stable side from ~$137k to ~$37k. The sell pressure is real, it is current, and it has nowhere else to go.

The per-pool numbers, measured at block 9,116,808 (2 August 2026):

Pool	Fee	USDRIF side	Stable side
USDRIF / USDT0	0.05%	153,986	~$37k
USDRIF / USDC.e	0.30%	44,392	~$62k
USDRIF / USDT	0.05%	86,574	14 USDT

Every balance is checkable on-chain: USDRIF/USDT0 0xd845702AF381f0405661747A6A20BDE0401a19d6 · USDRIF/USDC.e 0xbb29453a0a0d1566bb84924136c909e2d3f6b5f4 · USDRIF/USDT 0x69c4D1FcD58CBDd7f9857aC4F8d56A1Cc6B598Fe.

Pools like that don’t recover, and the reason is structural. An LP absorbing one-way selling ends up holding nothing but USDRIF, and a pool position can’t reach RIF on Chain redemption, so the inventory sits there permanently. The only deep way out pays RIF rather than a stablecoin, settles through a queue, and runs in one direction. There are also no limit orders, no scheduled execution, and no way for two holders to trade with each other.

What the protocol does

An intent is a signed statement of an outcome: what the user gives, what they must receive, any conditions attached, and whether the order may be filled in parts. The user signs it in their wallet. There’s no transaction, no gas, and no custody given up. Anyone can then execute it on-chain and keep whatever margin they can find, as long as they deliver at least the amount the user asked for.

The party doing that execution is a solver. We use filler and solver interchangeably below, and in our own code and the architecture diagram; they mean the same actor.

Three things follow from that:

• The settlement contract is the main validator. It records how much of each order has been filled and rejects anything that would exceed it, so an order can’t be replayed, double-spent or over-filled.
• Protection is in the code. Every order carries a minimum the user must receive. A filler offering less can’t complete the transaction at all; it reverts. Users don’t have to trust any particular filler, or us.
• Orders can be filled in parts. A large order doesn’t need one counterparty big enough to take all of it. Several fillers can each take a slice, at different prices and at different times, and the settlement contract tracks what’s left. The minimum applies to every slice, so partial execution never means a worse price.
• The filler pays the gas. A USDRIF holder who has never held rBTC can still trade. Token access is granted once through a shared permission layer instead of approving each trade.

What this adds to Rootstock

Order type	What it does
Market	Runs as a Dutch auction: the price starts in the user’s favour and decays until a filler takes it. Fills against whatever route wins — pool, resting order, or redemption
Limit	Rests until the named price is met, including prices the book hasn’t reached. A resting order can sit inside the spread and become the new best bid or ask
Scheduled (TWAP)	One slice per interval, so a treasury can exit or accumulate over hours or days instead of moving the market in one trade

How a market order finds its price. It isn’t an instant sweep at whatever the book says. The order opens at a price favourable to the user and decays over a set window until some filler decides the remaining margin is worth taking. Whichever filler moves first wins, so the user gets the best price the market will bear at that moment without having to know in advance what that price is. The decay is linear by default, or a piecewise curve if the order specifies one.

Two details that matter in practice. The decay carries an optional gas bump that scales with the block basefee, so an order stays fillable when gas spikes instead of stalling at a price no filler can afford. And an order may name an exclusive filler for an opening window, either blocking others outright or requiring them to beat that filler by a set margin. That is a choice the user makes on their own order, not curation by the protocol — the filler set itself stays open.

Every one of these can be partially filled, which is what makes size workable in a thin market. A holder wanting to sell 200,000 USDRIF doesn’t have to find a single filler willing to take 200,000. One filler takes what the pool supports, another takes what redemption supports, a third takes the rest an hour later, and the remainder rests in the book until someone does. The alternative — all-or-nothing execution — is exactly what forces large holders to walk a thin pool curve and eat the slippage.

The core primitive: redemption-backed fills

A filler pays a USDRIF seller out of its own stablecoin inventory and, in the same transaction, escrows that USDRIF into a RIF on Chain redemption. One signature from the user, no gas, no queue. The filler’s USDRIF doesn’t pile up, it cycles:

1. Pay the seller from stablecoin inventory, at or above the floor the contract enforces.
2. Escrow the received USDRIF into redemption in the same transaction, with a minimum-proceeds floor.
3. Receive RIF after 2–3 blocks. We measured a median of 65s across 49 real mainnet redemptions.
4. Sell the RIF back into stablecoin inventory, on the filler’s own schedule.

So the filler carries a 2–3 block RIF window per fill rather than an open-ended USDRIF position, and its capital turns over instead of being absorbed. That’s the difference between a market with redemption access and a pool without one, and it’s why the same one-way selling that killed the USDT pool is a workable business for a filler.

One caveat we’d rather raise ourselves: step 4 leans partly on off-chain RIF liquidity (CEXs), because on-chain RIF exit is only about $106k (July 2026) against a ~$85M market cap. That limits how fast a filler can turn its inventory over. It doesn’t limit what any individual user can sell, because the user is paid from standing inventory in step 1 and is finished at that point.

Why solving is open to anyone

• No whitelist, no application form. Any address that beats the price can fill the order. CoW Protocol and 1inch Fusion proved this model works, and both curate who is allowed to solve. Ours is open from the start.
• No capital barrier either. With in-transaction sourcing, a filler holding no inventory can pull the tokens from a DEX or aggregator inside the fill itself and still deliver the user’s minimum. The requirement is gas, not a balance sheet. It also sets the pricing floor: a solver routing through the existing aggregators is immediately at least as competitive as the best execution Rootstock offers today, and improves on it wherever redemption, minting or a resting order beats the pools.
• The economics work. Solver capital cycles instead of stranding: redemption serves USDRIF sellers, minting serves USDRIF buyers, and inventory returns to stablecoins either way. The margin is the spread between RIF on Chain’s mint and redemption rates and the prices on DEXs and CEXs — a solver earns wherever those disagree, which is what a passive LP in the dead pool never could.

Taken together, this is what eases and accelerates adoption: nothing to apply for, no capital to raise, nobody to wait on. A solver can be live the day it decides to be — and every solver that joins deepens the book for users.

Team Background

Core team building non-custodial DeFi infrastructure since 2023 with 1delta.

Name	Role	Contact	Links
Achim Huebl	Co-founder & CTO — protocol architecture, settlement contracts, redemption module	achim@1delta.io · Telegram @Achthar	LinkedIn · GitHub
Kevin Schellinger	Co-founder & CEO — go-to-market, filler and partner onboarding	kevin@1delta.io · Telegram @schellinger	LinkedIn

We’ve built such a pattern before. 1delta Unite is a 1inch Limit Order Protocol extension that opens margin positions against Aave and Morpho Blue, gasless for the user, with fillers holding no inventory. It took first place in 1inch’s “Expand Limit Order Protocol” track at ETHGlobal Unite DeFi (showcase). Signed orders, competing fillers, no gas and no custody isn’t something we’re figuring out on this grant.

In production. Our lending aggregation runs across 40+ chains and 300+ lending markets, with 150+ protocol deployments and $200M+ in transactions processed. Integrations cover Aave v2/v3, Compound V2/V3, Morpho Blue and Euler v2, written in Solidity and Yul. The Compound integration was audited by Certora. We also took first place at the StableHacks Grand Finale (Solana Foundation / Tenity / AMINA Bank).

We’ve had grants from Aave, Compound, Polygon and Mantle. Those funded a different product on a different codebase (looping with lending protocols).

Total Grant Amount

$35,000 total, milestone-gated. Requesting $3,000 for the first tranche (T1, released on approval).

Note on the tranche names: our first release is T1 rather than M1, because it exists only to book the audit slot. The M1 tranche of $13,000 follows once the milestone below is delivered.

The Strategic tier permits a 20% initial tranche, which would be $7,000 here. We’re asking for $3,000, and only to book the audit slot that makes the timeline work: that figure is 20% of the $15,000 audit line, which is a standard deposit to hold a reviewer’s slot. The core is already built, so we don’t need the DAO’s capital to reach M1. That leaves 91.4% of the grant behind on-chain outcomes anyone can check without trusting us.

Tranche	Released on	Amount	Cumulative
T1	Approval	$3,000 · 8.6%	$3,000
M1	Redemption path live	$13,000 · 37.1%	$16,000
M2	Audited & open	$7,000 · 20.0%	$23,000
M3	Volume	$6,000 · 17.1%	$29,000
M4	Scale & close	$6,000 · 17.1%	$35,000

Budget: independent audit and remediation $15,000 (43%) · protocol engineering, meaning the order backend, frontend and limit and scheduled orders $10,000 · filler and inventory tooling $5,500 · SDK, docs and the public analytics dashboard $4,500. We aren’t asking for filler inventory; fillers bring their own capital.

Milestone 1 Deliverables

Tranche: $13,000. All five deliverables below are required to unlock it.

#	Deliverable	KPI
a	Contracts deployed and verified	Live on Rootstock mainnet, verified on the explorer
b	Order backend live	Signed orders accepted, indexed and served to fillers
c	Public frontend live	Market swaps and limit orders end-to-end from a connected wallet
d	Real redemption-backed volume	≥$10,000 USDRIF filled, ≥25 fills, ≥10 addresses unrelated to 1delta, each combining payout and redemption in one transaction, under per-fill and cumulative caps we publish before the first fill; full transaction-hash list published
e	Audit engaged	Reviewer named, scope published, deposit paid

(a) and (b) are the protocol going live: contracts on mainnet, verified, with a backend that accepts signed orders, indexes them and serves them to fillers. (c) is the public interface, where a holder connects a wallet, places a market swap or a limit order, and signs once. (d) volume-based PoC: we prove that the system works on a smaller volume. (e) audit engagement: we book the audit (delivered via M2).

Why $10,000 and not more. Ecosystem-wide USDRIF DEX volume is around $54k/day, so $10,000 is about four and a half hours of flow that already happens. We set the bar low on purpose. This is pre-audit, and a milestone that needed a marketing push to clear would mean pushing unaudited contracts at people. The ≥25 fills across ≥10 addresses matter more than the dollar figure, because they show repeat use rather than one friendly transaction.

What M1 proves. That the loop closes. Each of those fills pays a user out of filler inventory and turns the received USDRIF back into working capital through redemption in the same transaction. Ten thousand dollars of throughput on a few thousand dollars of standing inventory is the measurable version of our claim: filler capital turns over where passive pool capital was absorbed and stranded. That’s the mechanism the dead USDRIF/USDT pool never had, running live with real users.

M1 is also to fix potential gaps. A small group of real users on mainnet tells us things a fork test can’t: which parts of the order flow are confusing, what a treasury actually wants from a scheduled order, whether the filler tooling is good enough for someone else to run, and which features we thought were done but aren’t. We’d rather learn that from ten early users before the audit than from eight thousand holders after it. Weeks 6–11 cover audit remediation, and they also cover whatever M1 tells us the product still needs, so what launches publicly at M2 has been through a real round of feedback rather than straight from our own testing.

About the risk before the audit. M1 needs at least 10 addresses that aren’t ours, so real people will be signing against contracts nobody has audited yet. We’re not going to pretend that’s fine. Here’s how we keep it small:

• A cap per fill and a cap on the total filled before the audit. We’ll set both from what early users actually need and publish them before the first fill, rather than pick a number now and have it be wrong in either direction.
• An unaudited-contract notice on the frontend for all of M1.
• No marketing to the wider holder base until the findings are fixed at M2.
• Those caps are enforced in the interface during M1, not by contract logic. That’s deliberate: the point of these limits is to bound exposure to code nobody has reviewed yet, so they can’t depend on that same code being correct.

We fill M1 ourselves, either from our own inventory or by sourcing on-chain inside the fill, so nobody else’s filler capital is at risk.

Milestones 2, 3 & 4

The Strategic tier requires four checkpoints.

Milestone	Deliverables	KPIs	Tranche
M2 — Audited & open	Audit report published, findings remediated and re-reviewed; public launch; open-source SDK and filler onboarding docs	≥1 filler we do not operate · ≥30 unique wallets	$7,000
M3 — Volume	Public analytics dashboard reporting volume, users, fills, committed filler inventory and pool depth	≥$400k cumulative qualifying volume, of which ≥$50k independently filled · ≥120 unique wallets	$6,000
M4 — Scale & close	Scheduled (TWAP) orders live in production; funding-efficiency report; retrospective AMA	≥$750k cumulative qualifying volume, of which ≥$150k independently filled · ≥$50k executed through scheduled orders · ≥250 unique wallets	$6,000

M2 is where three things land together. The audit report is published, with findings remediated and re-reviewed, which is what lets us market to the general holder base. The SDK, reference filler implementation and onboarding docs go out open source, so a filler operator can run one without talking to us. And at least one filler we don’t operate has to be live — the on-chain test of whether the open solver set is real, and the difference between a product we run and infrastructure other people use. The wallet floor of 30 is deliberately modest: until the findings are fixed we onboard users directly rather than marketing to the wider holder base, so every one of those wallets is hand-recruited. The step to 120 and 250 comes after launch, when marketing is allowed.

M3 puts the numbers in public. The analytics dashboard goes live, reporting volume, unique users, fill counts, committed filler inventory, USDRIF pool depth, and the split between independent fillers and our own. From then on the DAO doesn’t need our reports to check our numbers. The volume bar steps up to $400k cumulative with a $50k independent floor — sized to the fact that third-party fillers can only exist from week 11, when the SDK ships.

M4 is scale plus scheduled orders: $750k cumulative with a $150k independent floor, and at least $50k of that executed through TWAP orders. Scheduled execution is the use case that needs order-driven liquidity most — exiting size without walking a thin pool curve — and the $50k gate is objective and checkable on-chain, like everything else here. It closes with the funding-efficiency report and a retrospective AMA.

Counting rules. There are two independence tests and they do different jobs. User independence applies from M1 with no exceptions: no fill counts toward any KPI if the user side is an address we control. Filler independence applies from M2. We run the first filler by design, so rather than throwing that volume away we gate separately on a floor of volume settled by fillers we don’t operate. We chose a floor rather than a cap on our own share, because a cap would reward us for filling less.

Where the targets come from. M1’s $10k is about four and a half hours of current ecosystem USDRIF volume. M4’s $750k is roughly 11% of the flow the ecosystem already does over the same 18 weeks. The wallet ramp follows the marketing rules: 10 at M1 and 30 at M2 are hand-recruited during the pre-audit window; 120 at M3 and 250 at M4 come after public launch, and 250 is about 3% of the 8,239 current USDRIF holders over roughly seven weeks of availability. The independent-volume floors are sized to when third-party fillers can realistically exist: the SDK ships at M2 in week 11, so $50k by week 15 and $150k by week 18 assume $12–21k a week settled by fillers we don’t run. Every gated metric is volume or unique users, because those are things we can cause. Pool depth depends on third parties deciding to supply liquidity, so we report it monthly but don’t gate payment on it.

Value Commitment Plan. Our TVL target is $30,000 of filler inventory standing against USDRIF markets within 12 months post-funding — capital committed to filling, measurable on-chain at any block. If we miss it, we keep operating our own filler and maintaining the SDK and dashboard past grant close, and report the shortfall and the fix in the next Monthly Activity Report.

Note on FES: the 2.0× Strategic bar is met by the composite of TVL, users, volume and DAO engagement, all reported monthly.

How we reach these numbers

The KPIs depend on other people’s behaviour, so here’s how we plan to get it.

Fillers.

1. We run the first filler ourselves from M1, so the market works on day one and no user faces an empty book. That’s deliberate, and it’s why M1 volume may be self-filled.
2. We publish the reference filler implementation, the SDK and onboarding docs at M2, so an operator can run one without talking to us.
3. We recruit directly: DEX and DEX-aggregator teams already routing on Rootstock, market makers active here, and existing solver teams looking for markets with less competition.
4. The barrier is low on purpose. With in-transaction sourcing a filler needs gas rather than a balance sheet, so a new entrant doesn’t have to raise inventory before competing.
5. M2 is gated on a filler we don’t operate, so this gets measured rather than assumed.

Users.

1. We line up the first users during the forum and AMA period, before T1 lands, so M1 doesn’t start from zero — treasuries, DAOs, market makers and wallets that already hold USDRIF and want a way out of it. The frontend they trade through carries the unaudited-contract warning from day one.
2. The public frontend is live from M1, with an unaudited-contract notice throughout the pre-audit period.
3. General launch comes only after remediation at M2, to the 8,239 existing USDRIF holders.
4. The SDK lets wallets and aggregators route into the order book. An aggregator that improves price discovery over existing depth is complementary to us rather than competing. We’re also open to surfacing the flow in ecosystem interfaces — wallets or Collective surfaces — if there’s interest; the SDK is built for that.
5. Treasury-sized users for TWAP at M4, aimed at holders who need to exit size without walking the pool curve.

If the numbers lag. We keep operating and capitalising our own filler past grant close, keep the SDK, reference filler and dashboard maintained and open, and onboard fillers and treasury users directly until the value lands. The shortfall and what we’re doing about it go into the Monthly Activity Report that catches it, not the one after the next milestone.

How it is measured

On-chain data is the source of truth. Every fill is a transaction and every order is a signature that verifies against the settlement contract, so none of this rests on numbers we report about ourselves.

What	How it’s measured	Where it’s published
Volume, fill count, unique wallets	On-chain, from settlement events	Monthly report; public dashboard from M3
M1’s ≥$10,000	Full transaction-hash list, each fill and its matching redemption checkable independently	Published at M1
Independent vs own-filler split	Filler address on each settlement	Monthly report, listed separately
TVL delta (committed filler inventory)	Token balances of filler contracts, readable at any block	Monthly report; dashboard
USDRIF pool depth	Pool reserves	Monthly report; dashboard — reported, not gated

Monthly Activity Reports go on Discourse between every milestone, using the standard template. On-chain: transaction count, TVL delta, new wallets and unique users, volume processed. Off-chain: product progress, user and filler pipeline, social reach, and blockers with the corrective action taken. Milestone AMAs at each checkpoint, plus a final retrospective.

Timeline

About 4 months from T1 landing. The governance steps run first and aren’t counted in that: KYB and Persona verification, 1–3 weeks of forum discussion, the initial AMA, on-chain submission (1,000 stRIF plus gas, which we’ll hold before posting), the 7-day vote, and the timelock.

Weeks	Engineering	Go-to-market	Gate
1–5	Order backend to production (order intake, indexing, filler feed); public frontend; mainnet deploy and explorer verification; redemption filler live and funded	First users onboarded; frontend carries the unaudited-contract notice; first fills executed and hashes published	M1
6–11	Audit execution and remediation; re-review; SDK packaged and published; reference filler implementation and onboarding docs	Public launch after remediation; filler recruitment — direct outreach to DEX and aggregator teams, Rootstock market makers, and existing solver teams	M2
12–15	Public analytics dashboard; scheduled (TWAP) order rollout	Treasury and DAO outreach for scheduled exits; aggregator and wallet integration conversations via the SDK	M3
16–18	Hardening, dashboard completion, funding-efficiency reporting	KPI close-out, retrospective AMA	M4

What’s already built. The settlement core, shared permission layer, order and scheduling model, USDRIF redemption module and the redemption filler are implemented and tested against a Rootstock mainnet fork using the live RIF on Chain, USDRIF, RIF and USDT0 contracts. Weeks 1–5 are productionisation and deployment rather than research, which is why M1 is a five-week milestone and not a discovery phase.

Technical Specs

Architecture. Three pieces: a settlement contract that verifies signatures and tracks fill state, a shared permission layer that holds token allowances, and per-market modules (for USDRIF, the RIF on Chain redemption module). Fillers run their own contracts and aren’t part of the protocol.

The order splits into two halves. Validators are the conditions — when the order may execute: a price level, a health factor, a deadline, or any predicate that has to hold on-chain. Execution modules are the actions — what actually happens: a swap, a redemption, a stake, a lending operation. The settlement contract checks the validators, runs the modules, and either completes the whole thing or reverts it. That is what lets one signature express something other than a swap, and it’s why adding a market means writing a module rather than changing the core.

What this grant covers. The settlement core, the permission layer, and the USDRIF solver contracts — filling orders via RIF on Chain mint and redemption — plus the order types that sit on top of them.

Admin roles: none. Settlement takes one constructor argument and exposes no owner, no admin role and no pause. The permission layer has no admin either. Upgradeability: none. No proxy, no initializer, no upgrade path. Once deployed, the contracts are final. The only privileged call over user funds belongs to the holder, who can revoke their own allowance at any time.

External dependencies. RIF on Chain for redemption and minting, with its price provider, and the USDRIF, RIF and USDT0 tokens. For routing, solvers source through whichever venue quotes best — Uniswap v3 via Oku’s router, SushiSwap, Nordstern and the other DEXs and aggregators on Rootstock. None of those is a hard dependency: they’re interchangeable routes, and any one can stand in for another. No bridges, and no custom oracle: we use RIF on Chain’s own price provider and enforce a minimum-proceeds floor rather than trusting a feed.

What we measured. Queue parameters read live from the RIF on Chain queue (minOperWaitingBlk = 1, maxOperWaitingBlk = 3). Across 49 real mainnet redemptions every one settled inside the 2–3 block window, with a median of 65s and none expired or reverted. The redemption fee is a flat 0.25% charged in RIF and the execution fee a flat 0.0000029364 rBTC regardless of size, so a filler’s costs per fill are predictable enough to quote a floor in advance. Two examples, both checkable on Blockscout:

	Median case	Slowest observed
Operation	2209	2076
Request → settlement	block 9,047,098 → 9,047,101	block 8,987,800 → 8,987,802
Elapsed	3 blocks · 65s	2 blocks · 144s
USDRIF redeemed	1,000.000000	2,000.000000
RIF received, net of fee	8,512.937942	29,055.551038

What happens when something fails. The fill is atomic: either the user is paid and the USDRIF is escrowed into redemption in the same transaction, or the whole transaction reverts and nothing moved. If the redemption later can’t meet its floor, the queued operation errors and RIF on Chain refunds the escrowed USDRIF to the filler — a retry for the filler, not a loss, and the user was already paid either way. We tested both paths against the live contracts on the fork.

Audit status. These contracts are new and they haven’t been audited yet. That’s what this grant buys, and it’s 43% of the budget.

That share is worth explaining, because a grant that ports an already-audited product onto Rootstock carries no such line at all. This isn’t a redeployment. The settlement core, the shared permission layer and the USDRIF redemption module are new code implementing something that doesn’t exist on Rootstock today, and new code that moves user funds on the strength of a signature needs review before anyone is asked to trust it.

Three things offset the novelty. We’ve shipped this pattern before, on 1inch. The mechanism is already tested against live RIF on Chain contracts on a mainnet fork. And M1 proves it works on mainnet before the DAO funds the rest.

Sequence. Reviewer named and deposit paid at T1, audit engaged at M1, report published with findings remediated and re-reviewed at M2, and public launch gated on remediation. We’re not naming a firm in this post because governance takes six to eight weeks from posting to first disbursement, and a quote we gathered today would be stale before we could act on it. The $15,000 line is sized above the $11k quote a cohort-1 builder reported in the guidelines thread.

Status. Nothing is on mainnet yet. Deployment is M1.

Value Prop for Rootstock

• Permissionless solving, on Rootstock first. The solver set is open from the start and stays open, because the contracts have no admin who could close it. Nothing on Rootstock works this way today. That is a property of Rootstock infrastructure the Collective can point at, not just a feature of one app.
• USDRIF Adoption. This addresses the measured constraint on USDRIF utility directly. Wallet swaps, treasury exits and payment rails all need a predictable exit, and holders get to leave into any stablecoin on demand instead of queueing for RIF.
• TVL Movers. The capital we attract is filler inventory committed to USDRIF markets, and we carry a $30,000 TVL target on it in the Value Commitment Plan. We report pool depth monthly but don’t gate on it, because that’s a third-party decision and filled volume is what we can cause.
• Rootstock Onboarding UX. A USDRIF holder can trade without holding rBTC at all, because the filler pays gas. Time-to-first-transaction comes down to a wallet signature.
• RIF Economy Enablers. Every redemption-backed fill routes through RIF on Chain and creates RIF flow, into a market with only about $106k of on-chain exit against a ~$85M market cap. That’s recurring RIF demand as a by-product of normal business rather than one-off incentive spend.
• Public good. The contracts, SDK, reference filler and analytics dashboard are open source, the order book is permissionless, and anyone can run a filler, including against us.
• Built here first. Rootstock is the first deployment target, not a port of something already running elsewhere. That’s why it needs a full audit, and it’s also why the Collective ends up with a primitive no other chain has rather than a copy of one they already do.
• Nobody else is bringing it. CoW Protocol and 1inch Fusion proved this model on EVM chains. Neither is on Rootstock and neither has announced plans to deploy here, and both curate their solver set where ours is open from the start.

Demo and GitHub repo

• Interface mock: https://intents-demo.pages.dev/ — a clickable mock of how the app will work: an order book separating pool, limit-order and redemption-backed depth, limit and TWAP order entry, and the gasless signing flow. It is a design mock, not a live app. Nothing is connected to a network and the numbers in it are illustrative rather than measured. The measured figures in this proposal come from the on-chain sources described above, not from the mock.
• GitHub: https://github.com/1delta-DAO — the exact repo will be published upon deployment
• Prior art, similar pattern: 1delta Unite — ETHGlobal showcase
• Protocol repositories for this work: the settlement core is published when it is finalised, before it is deployed to mainnet at M1, so the deployed code can be checked against source. The SDK and reference filler follow at M2.

Video Pitch

https://youtu.be/q-KigcOi1q8 — Fully Decentralized & Permissionless Intents on Rootstock Network

---

This is a lot to digest — we’d rather give the Collective too much to check than too little.

We’re glad to dig into any figure, assumption or design decision, here in the thread or at the AMA.

Hoping to hear from you soon — we’re excited about your feedback, and even more about building this on Rootstock.

[LEGOSI]

Desde mi perspectiva personal, la propuesta aborda una problemática enfocada en un activo muy importante dentro del ecosistema como lo es USDRIF. Entiendo que esta baja liquidez de salida limita también su transaccionalidad (utilidad) como activo y afecta directamente la experiencia del usuario.

No he profundizado lo suficiente como para valorar hasta qué punto un modelo basado en intents puede aportar una capa de ejecución más eficiente y flexible que los AMM tradicionales. Sin embargo, valoro positivamente que se estén buscando soluciones para un activo que, desde mi punto de vista, tiene la capacidad de atraer una liquidez mucho mayor si sus cimientos terminan siendo sólidos.

Otro aspecto que considero muy positivo es la construcción con un enfoque de código abierto, lo cual abre camino a la cooperación distribuida propia del efecto de red de Rootstock, además de ser un protocolo permissionless, permitiendo que cualquier participante pueda involucrarse. Pienso que esto puede generar una tracción interesante, especialmente porque en una primera etapa usuarios minoristas podremos probar la infraestructura con montos relativamente bajos y, al mismo tiempo, aportar validación temprana al sistema como una pieza importante dentro de la arquitectura de USDRIF.

En la misma línea, y siendo un poco más crítico, también considero que varios de los KPIs están muy ligados al comportamiento de terceros y no únicamente a la capacidad de ejecución del equipo. El volumen negociado, la incorporación de solvers independientes y la liquidez comprometida dependen en gran medida de la adopción del mercado, lo que deja espacio para resultados inciertos. Me gustaría conocer cuál sería la estrategia si esa adopción ocurre más lentamente de lo esperado o si los solvers independientes tardan en aparecer, aun cuando el producto funcione correctamente desde el punto de vista técnico.

También creo que el modelo económico merece un poco más de profundidad. La propuesta asume que las diferencias de precio entre RIF on Chain, los DEX y la liquidez externa generarán incentivos suficientes para mantener un mercado competitivo de solvers, pero no presenta escenarios donde esos márgenes se reduzcan de forma significativa. Una simulación bajo diferentes condiciones de mercado ayudaría a entender mejor la sostenibilidad del modelo a largo plazo y qué incentivos tendrán nuevos participantes para inmovilizar capital y operar como solvers una vez finalizado el grant.

Respecto al presupuesto solicitado, destinar una parte importante del grant a una auditoría de seguridad me parece razonable considerando que se trata de contratos completamente nuevos que manejarán activos mediante firmas off-chain y liquidaciones on-chain. Hablamos además de contratos que serán inmutables. Valoro mucho que no existan privilegios administrativos ni mecanismos de control centralizado, pero justamente esa misma decisión hace que cualquier vulnerabilidad que pase desapercibida durante la auditoría pueda ser mucho más difícil de mitigar una vez desplegado el protocolo. Me gustaría conocer con mayor detalle cuál sería el procedimiento operativo ante un escenario de ese tipo.

Finalmente, un aspecto que personalmente utilizaría para medir el éxito del proyecto no sería únicamente el volumen procesado o la cantidad de usuarios, sino también indicadores como la reducción del slippage, la mejora en el precio de ejecución frente a las alternativas actuales, el tiempo promedio de ejecución de las órdenes y el crecimiento sostenido de solvers independientes. Creo que esos indicadores permitirían medir de forma más directa si el protocolo realmente mejora la experiencia de los usuarios y fortalece la liquidez de USDRIF.

En términos generales considero que es una propuesta innovadora que intenta resolver un problema real dentro del ecosistema de Rootstock. Sin embargo, antes de apoyar su aprobación me gustaría contar con mayor evidencia sobre la sostenibilidad económica del modelo de solvers, la gestión del riesgo derivada de la inmutabilidad de los contratos y un plan más detallado para garantizar la adopción una vez finalizado el período del grant.

[Achthar]

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:

1. 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.
2. 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.
3. Disclose publicly within 24 hours: forum and channels: with the affected contract, the nature of the issue, and the user action required.
4. 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.
5. 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.

[Tane]

Thanks @Achthar, this is one of the most measurable grant proposals we have seen under the current guidelines, and the route data you shared in reply to @LEGOSI answered the solver-economics question with measurements rather than assertions.

We have three requests before on-chain submission.

@Achthar

We line up the first users during the forum and AMA period, before T1 lands, so M1 doesn’t start from zero

We would like to see them before the vote: named treasuries, market makers, or wallets committed to trading at M1, even informally.

@Achthar

the settlement core is published when it is finalised, before it is deployed to mainnet at M1, so the deployed code can be checked against source.

Publishing it before the vote rather than before deployment would let delegates check the already-built claim while it can still inform the decision.

The tranche structure should also include the roughly 30% terminal post-completion holdback introduced in the V3.2.2 patch, released only after an impact review against the targets in this proposal. As structured, M4 pays on its own KPIs with nothing held behind that review.

We lean toward supporting if the first two land before submission.

[Curia]

@Achthar Great vision to bring a similar CoW and 1inch solver model to Rootstock and make the solver set permissionless. The economics of how a solver fronts stablecoin to the user and recovers through redemption are clear from your reply, so we won’t reopen that.

Our main concern is whether solver (filler) participation lasts over time. You have made the case that solving is a self-sustaining business and that you cannot force independent solvers, only give them order flow to compete for. We follow that. What is still open for us is retention, not appearance, and the risk a solver actually carries. M1 is self-filled, so it proves the mechanism, not the market. You flagged the RIF price risk on the recovery leg yourself and pointed to hedging on Binance Futures. The solver takes in USDRIF, redeems it into RIF, then has to sell that RIF back to stablecoin, and it is exposed to RIF’s price until it exits. Two things we would want to see: RIF’s recent realized volatility and how much exposure that leg carries before the solver is back in stablecoin, and how the hedge closes it. And on the margin you already measured for 2 to 5 August, would it have covered the hedging cost at that size? We are not asking you to predict RIF. We are asking whether the risk a second solver takes on is small enough, against a margin that can rotate to zero on one side within days, to make staying worth it.

Lastly, on releasing funds, we’d prefer payments to be tied to market validation rather than deployment alone. As structured today, up to $23k (~66% of the total grant) can be released before any independent filler volume is demonstrated, since M2 only requires an external filler to exist not that it executes meaningful volume. We’d support adding a modest independent filler volume requirement to M2.

[ChronoTrigger]

@Achthar, this is a problem worth solving and the case for it is well made. I myself have swapped out of USDRIF myself and didn’t have a good experience, so the demand side sounds real not assumed, and the pool table makes it hard to argue with. Improving that exit path matters for anyone who actually uses the stablecoin.

A few questions/observations/suggestions:

On which way the RIF flows:
A redemption-backed fill leaves the filler holding RIF that it then has to sell, and you note that on-chain RIF exit is only around $106k. Using the numbers in your own redemption table, the $750k target at M4 works out to something like 6 million RIF looking for a buyer, if most of that volume is people selling USDRIF. Minting runs the other way and does create RIF demand, but the problem you describe is one-way selling, so the two sides are unlikely to be even. Listed under RIF Economy Enablers it reads as demand, when at scale a good part of it is supply. We would suggest splitting qualifying volume into redemption side and mint side in the monthly reports from M1, and possibly a mint-side floor at M3 and M4 instead of one combined number.

On the audit:
It is 43% of the budget and the firm is not named yet. The point about quotes going stale over six to eight weeks is fair, but a shortlist and the scope do not go stale, and both could sit in this thread before the vote. It matters more here than on a normal grant for the reason @LEGOSI raised. There is no pause and no upgrade path, so once the contracts are live that audit is the only review that will ever happen. If something serious gets missed, the fix is a new deployment and moving users across, and nothing in the budget covers that. We would suggest M2 be worded as all high and critical findings closed and re-reviewed, rather than findings remediated.

On the TVL commitment:
The $30,000 target is filler inventory, and you run the first filler, so it can be met by moving your own $30,000 into the filler contract and leaving it there. That is your capital changing pockets rather than new capital coming to Rootstock. The independent filler floors at M3 and M4 already ask for someone else to show up and put money to work, so we would suggest the TVL commitment carry an independent share as well. With the volume split and the audit scope in the thread before submission, we would be comfortable supporting this.

[Achthar]

Thank you for the feedback.

1. Named early users, before the vote

That makes sense.

Outreach is underway on three fronts, and we will post what we have in this thread before on-chain submission - counterparty, what they intend to trade, and rough size:

• Solvers and market makers: In talks with several solvers from our own network, having worked with them before
• Wallets and holders: reaching out directly and through protocol channels (Discord, Telegram)
• Treasuries: Existing Rootstock projects, for scheduled exits and rebalancing. Protocol treasuries are the natural fit here, and we would eventually want to serve the Rootstock Foundation

At M1 the contracts are unaudited, so what a project can sensibly commit to is testing at small size, not routing a treasury through it. Treasury-scale usage is an M4 deliverable, after remediation.

The list could say which category each name falls into, and where someone prefers not to be named we would say so and could offer verification privately.

2. Publishing the settlement core before the vote

We will publish the settlement core as soon as possible and for sure before the onchain vote. Will keep you posted on this.

3. The terminal holdback

We could restructure it so that 28.6% sits behind a post-completion impact review: $1,000 comes off M1 and M3, $2,000 off M2, and all $4,000 moves to M4.

Tranche	Released on	Amount	%
T1	Approval	$3,000	8.6%
M1	Redemption path live	$12,000	34.3%
M2	Audited & open, plus independent solver volume	$5,000	14.3%
M3	Volume	$5,000	14.3%
M4	KPIs met and impact review passed	$10,000	28.6%

So there would be no milestone or KPI changes - only the amounts, and that M4 is now conditional on the review rather than on its KPIs alone. Wuld anchor the review to the Value Commitment Plan horizon: 12 months post-funding, against the figures already committed there.

[Achthar]

Thank you for the feedback.

The data

The solver is long RIF from redemption settling until it is back in stablecoin. Two windows matter: the redemption itself (median 65s, measured across 49 mainnet redemptions) and a CEX deposit if the RIF is recycled off-chain (~10 minutes).

1σ of RIF over each, measured on Binance 1-minute bars, against the 89 bps margin we measured on 2 August:

	65s redemption	10 min deposit
Normal day	0.31% - margin covers 2.8σ	0.95% - covers 0.9σ
Stressed day (21/23 July)	0.74% - covers 1.2σ	2.24% - covers 0.4σ

Stressed days are real: four days in the last 90 moved more than 25%, the largest +52%.

Unhedged

Inside the redemption window on a normal day, the margin covers 2.8σ. A solver that closes the cycle there does not need a hedge at all.

Hedged

Everything else - the 10-minute deposit, or any stressed day - is inside 1σ, so it has to be hedged. Binance lists a RIFUSDT perpetual: short on fill, close when the RIF is sold. Cost is 0.04% taker each side plus funding, about 8 bps, which holds in stressed conditions as well.

	2 August	5 August
Margin, redemption route	89 bps	~0 bps
Hedge cost	8.1 bps	8.1 bps
Net	80.9 bps	use DEX instead

So yes on 2 August - about 81 bps on a delta-neutral cycle. On 5 August the redemption side did not cover its own hedge and a solver would not fill it; the mint side was profitable that day.

The perp book absorbs ~$11k at top of book and $23k within 1%, so fills up to roughly $20k hedge cleanly.

Whether it is worth staying

The risk you are asking about costs 8 bps to remove, against a margin an order of magnitude larger. A solver that hedges is not exposed to RIF; it is exposed to whether there is enough flow to cover its fixed costs. That is why we keep coming back to order flow rather than solver count. On top, the regular DEX route is always an option, too.

M2 and independent volume

We could add to M2: ≥$10,000 settled by solvers we do not operate, read on-chain from the solver address on each fill.

We would also ship the SDK and reference solver in M1 instead of M2, so an external team has time to integrate before that gate.

With the tranches proposed in Tane’s thread (T1 $3,000, M1 $12,000, M2 $5,000, M3 $5,000, M4 $10,000):

	Now	Proposed
Released before any independent volume	$23,000 (66%)	$15,000 (43%)
Released before the impact review	100%	71%

[Achthar]

Hi @ChronoTrigger

Thank you for the feedback!

Which way the RIF flows

You are right, and the framing in the proposal is wrong. A redemption-backed fill releases RIF from collateral and the solver then sells it - that is RIF supply. Only the mint side is demand. Listing it under RIF Economy Enablers without that distinction overstates the case, and we would correct the wording to RIF flow.

Your arithmetic is correct: $750k at the Appendix A rate is ~6.4M RIF. For scale, that is ~$6k/day spread over 18 weeks, against ~$34.7M/day of RIF volume - though only ~$106k of that is on-chain, which is the constraint we flagged. The direction point stands regardless of size.

One qualification: the two sides are coupled rather than independent. One-way selling moves the price, and the price move is what invites the other direction. We measured that happening - between 2 and 5 August the USDT0 pool went from 153,986 USDRIF against $37k of USDT0 to 66,688 against $124k, and the profitable arbitrage flipped from the redemption side to the mint side over the same days. Sustained selling is what creates the incentive that pulls the other way.

That does not make the sides even, which is why we would split qualifying volume into redemption side and mint side in the monthly reports from M1.

On the floor: we could add ≥$50k mint-side at M3 and ≥$100k at M4, alongside the existing cumulative targets. Roughly 12% of each - and the mint route is the profitable side at current prices, so it should not be the binding constraint.

Audit

The auditor would be one of the providers listed on Areta - we are in talks with several. We would post the scope in this thread, and the firm we pick before the on-chain vote.

We would also take your M2 wording: all high and critical findings closed and re-reviewed, rather than “findings remediated”.

On the wider point: with no pause and no upgrade path, a serious miss means a new deployment and migrating users, and nothing in the budget covers that. What bounds it is that the contracts hold no funds at rest - exposure is outstanding allowances, revocable by the holder at any time. That is not a substitute for the audit being right.

TVL commitment

Also correct. $30,000 of our own inventory in our own solver is capital changing pockets.

We could split the target: of the $30,000, a share has to come from solvers we do not operate. $10,000 would be consistent with the independent-volume floors at M3 and M4. Our own inventory would still be reported, separately.

[iamChekwube]

The proposal introduces 1delta Intents, a permissionless intent settlement protocol built on Rootstock to improve USDRIF liquidity. Instead of users executing swaps directly, they sign an intent while independent solvers compete to provide the best execution. The protocol is immutable, non-custodial, and designed without admin controls, ensuring the solver network remains permanently open. Its first use case focuses on solving USDRIF’s current liquidity constraints through redemption-backed settlement, while also introducing market, limit, and TWAP orders.

Assessment (Pros & Cons)

The proposal clearly addresses a real and measurable liquidity issue within the Rootstock ecosystem using on-chain data rather than assumptions. The permissionless solver model is a strong differentiator, and the milestone-based funding with measurable KPIs provides accountability throughout development. The team’s previous experience also adds credibility to their ability to execute the project.

On the other hand, the proposal is highly technical, making it difficult for non-technical community members to fully evaluate. It also depends on attracting independent solvers after launch, but there is limited evidence of existing demand from potential operators. Additionally, the adoption strategy could be explained more clearly.

Suggestions for Improvement

1. Include a simple architecture diagram or workflow to make the protocol easier to understand.
2. Add a short executive summary highlighting the problem, solution, and expected ecosystem impact for governance voters.
3. Expand the adoption strategy by explaining how wallets, DAOs, and external solver operators will be onboarded.
4. Include additional success metrics, such as reduced slippage or improved execution quality, alongside volume-based KPIs.

Overall, this is a strong and technically well-researched proposal that addresses a genuine problem in the Rootstock ecosystem. Improving accessibility for non-technical reviewers and strengthening the adoption narrative would make it even more compelling.

[Achthar]

Good point! It makes sense to have a more concise version.

Before adding it to the overall version, I write it down here for further feedback:

Executive summary

The problem

• USDRIF is easy to mint or buy, and hard to sell.
• Its three DEX pools are thin and one-sided. One is dead: 86,574 USDRIF against 14 USDT.
• Size gets punished. A $100,000 purchase of USDRIF on the DEX returns 66,466 USDRIF - about a third lost to slippage.
• The only deep exit is RIF on Chain redemption, which pays RIF, not a stablecoin, settles through a queue, and runs one way.

How it works

• The user signs an intent - what they give, what they must receive. No transaction, no gas, no custody given up.
• Solvers compete to fill it and keep whatever margin they find. Best price wins.
• The solver picks the route at execution time: DEX, CEX, or RIF on Chain mint/redemption. The user does not have to know which is best.
• The minimum is enforced by the contract. A solver offering less cannot complete the transaction at all.

Why it stays open

• No whitelist, no application form. Any address that beats the price can fill.
• No inventory needed. A solver can source the tokens inside the fill itself, so the barrier is gas, not a balance sheet.
• No admin, no pause, no upgrade path. Once deployed, nobody can close the solver set - including us.

What it adds

• Market orders run as a Dutch auction: the price starts in the user’s favour and decays until a solver takes it.
• Limit orders, including at prices the book has not reached.
• Scheduled (TWAP) orders, so a treasury can exit over hours or days instead of in one trade.
• Every order can be partially filled, so size does not need a single counterparty.

Architecture

• Settlement contract: verifies the signature, tracks how much of each order is filled, runs the modules atomically or reverts.
• Validators are the conditions; execution modules are the actions.
• Adding a market means writing a module, not changing the core.

Who adopts it, and how

Solvers

• Teams in our own network, who already run solvers elsewhere.
• Aggregators already routing on Rootstock - they have the flow and the infrastructure.
• The reference solver and SDK are open source, so a new operator needs no permission and no conversation with us.

Users

• We run the (open source) swap interface ourselves from M1, so there is somewhere to trade on day one.
• Wallets route in through the SDK and get a swap UI without building settlement.
• After the audit, marketing to the existing USDRIF and RIF holder base.
• Down the road: tailored modules for Rootstock ecosystem projects: a protocol that needs a specific action gets a module rather than a workaround.

Treasuries and DAOs

• Scheduled orders, for exiting size without walking a thin pool.

Impact for Rootstock

• A working exit for USDRIF holders, at a better price at size.
• RIF flow through RIF on Chain in both directions - redemption and mint.
• Settlement core, SDK, reference solver and dashboard are open source. Anyone can run a solver, including against us.
• Rootstock gets the primitive first, and it stays open because the contracts have no admin who could close it.

How success is measured

• Volume, unique wallets and fill counts, read on-chain from settlement events.
• Price improvement against the best single-venue route at the same block.
• Time from signature to settlement.
• Independent solvers over time, and the split between their volume and our own.

The ask

• $35,000, milestone-gated. 8.6% on approval; the rest behind delivered on-chain outcomes.
• The audit is 43% of the budget - these contracts are new, and they are immutable.

[Achthar]

Hi @Tane

Te codebase is now public: GitHub - 1delta-DAO/1delta-X · GitHub

[Tane]

Thanks! We’ve gone through the repo. The settlement core, permit3, the execution modules and the SDK are all there, and the README is straightforward that the three security reviews so far are internal and there is no external audit yet. That closes the publish-before-vote request from our earlier review.

The named early-users list is the one item still open from that review; we’ll look for it here before the on-chain submission.