-
Project Name & Description
DZAP is an intent-based execution layer that turns multi-step DeFi actions into a single click. This grant funds a one-click RIF staking flow on Rootstock: a user picks any supported asset and amount and DZap handles swap → stake in one batched, atomic transaction, removing the hurdles with manual swaps. Making staking a one click seamless operation. -
Team Background
Built by a globally distributed team of ~15, with 8+ years of blockchain development experience and a track record of launching and scaling products across multiple chains.- Shivam Chopra, Founder: LinkedIn - shivamdev , TG: @shivam0x
- Abhijeet Maurya, CTO: LinkedIn - abhijeet0x , TG: @abhijeet_0x
-
Total Grant Amount
$4,500, requesting $1350 for Milestone 1 -
Milestone 1 Deliverables
Protocol indexing - Completed -
Milestone 2 & 3
Execution layer setup (RIF staking contracts integrated) - In Progress -
Timeline
~2 Weeks -
Technical Specs
- Architecture: input asset → swap into RIF → stake → stRIF returned, batched into one atomic execution.- Audit status: DZap’s contracts are already audited — details here: Security & Audits - DZap
-
**Value Prop for Rootstock
Solution - 1 Click Staking
**
User: selects input asset + amount → confirms once. DZap: swaps into RIF → stakes → returns stRIF, batched into one atomic action.We expect the flow to onboard new users into RIF staking and route recurring swap + stake volume over the measurement window. We’ll publish live numbers on the dashboard from launch and work with the collective to enhance coverage.
Measured via: on-chain data (wallets, volume, stRIF positions) as the source of truth, surfaced on a public dashboard linked in each monthly report.
-
**Demo and GitHub repo
Website: Dzap.io
Github:** GitHub - DZapIO/DZapZappingContracts · GitHub
Demo: ⚡DZap on X: "Liquidity onboarding should not be a fragmented multi-step process. Most users today still need to: Bridge → Swap → Balance assets → Approve → Add LP DZap converts this entire flow into one seamless transaction. The attached video shows how simple the end-user experience https://t.co/KXGBdLihks" / X -
Video Pitch:
Sample Flow: https://youtube.com/shorts/nmn2ZcMo3OQ?si=a0-Rh3b_F8PHQ4yb
Really excited to see this coming together! Making RIF staking a simple one-click flow is going to be a great experience. Looking forward to shipping this 
Hi @dzap thanks for this proposal. What assets do you plan to support and where is the liquidity coming from?
Hey @Axia thanks for your query. The liquidity is sourced from all the protocols on Rootstock indexed by DZap . For liquidity, we’ll aggregate from the existing DEX ecosystem and available liquidity venues on Rootstock.
Our routing engine will then source the best available execution across these venues, ensuring competitive pricing, efficient swaps and minimal slippage for users.
We will be enabling this feature for any asset across the Rootstock Network.
Hi @dzap thank you for the proposal.
We have two questions:
-
First, the success of any intent-based architecture ultimately depends on the solver ecosystem. The key advantage of intents comes from having a sufficiently large and competitive set of solvers that can compete to provide users with the best possible execution. How do you plan to address this aspect? Will you operate your own solvers, or do you intend to rely on an existing intents infrastructure provider? Or is the proposal actually focused on a DEX aggregator for swaps rather than a full intent-based architecture? We would appreciate more detail on how the proposed intent-based mechanism works in practice and how execution will be handled.
-
Second, the V3.2 Grants Guidelines require verifiable on-chain projections and metrics demonstrating that the requested grant is expected to generate a measurable impact on Rootstock. Accordingly, we would appreciate if you could provide your projected transaction volume and TVL targets, the expected timeline for achieving them, and the assumptions supporting those projections.
Hello @SEEDGov great questions, happy to clarify both.
**On intent architecture and solver dependency**
There’s a distinction worth drawing here: DZap uses intent-based UX, but we’re not an intent settlement protocol that relies on a competitive solver marketplace.
When a user submits an intent: in this case, “stake my assets into RIF” , DZap’s own graph based routing engine computes the optimal execution path and handles it directly using existing on-chain liquidity venues: DEXs, bridges on the target protocol (Rootstock) itself.
No external solver network is involved and the success of this integration isn’t contingent on building or attracting one.
For this proposal specifically, the flow is:
- User selects input asset and amount
- DZap routes and executes the swap into RIF
- RIF is staked automatically
- User receives stRIF
One confirmation. That’s it and steps 2-4 executed.
We orchestrate the full execution path which is also why we can offer meaningful reliability and latency guarantees, rather than being dependent on any one solver competition, we support all that are live on Rootstock for supreme quality.
— Part 2
**On projected impact and verifiable metrics**
The simplest way to frame this: staking RIF already works.
DZap doesn’t replace it, we collapse the existing manual steps that currently sit in front of it (acquiring the right token, approving, then staking as a separate transaction) → into 1-click.
With 35M+ RIF already staked and the ABI sitting around 30%, the demand is demonstrably there. The friction is the journey.
Our projections reflect that:
- **70–80%** of staking volume from users who currently need a token swap routed through the one-click flow
- **~90%** adoption for first-time stakers, where onboarding friction is the most common drop-off point
We’ll publish a public dashboard from day one tracking:
- Unique wallets staking through DZap
- Total transactions executed
- Total volume routed into RIF staking
All on-chain and fully verifiable. We’ll also include these numbers in monthly reports.
We didn’t frame our KPIs around total RIF staking TVL because that’s influenced by market conditions, ecosystem incentives and broad protocol activity above and beyond our integration.
The metrics above isolate DZap’s direct contribution, which we think gives a more honest picture of impact post activation.
Longer term, once this foundation is live, we can plan to include cross-chain and also gasless execution options, so users can stake into RIF from assets held on Ethereum, Arbitrum, or elsewhere without touching rBTC first.
That’s the broader vision, but the grant scope is the core one-click flow.
Happy to answer any follow-ups or share a technical spec if that would help move things forward.
Hi @dzap — appreciate the responsiveness.
This proposal fits two of the 2026 Strategic Themes pretty directly: RIF Economy Enablers (creating genuine RIF demand) and Rootstock Onboarding UX (reducing time-to-first-transaction). The idea that ~30% staking participation is capped by UX friction rather than lack of interest — is worth testing, and at $1,350 for M1 it’s a budget friendly way to find out.
Measurability is also a high-weight criterion (“unmeasurable = unfundable”). The percentages you shared (70–80% of staking volume, ~90% first-time adoption) aren’t targets without a baseline. Could you give absolute numbers — expected wallets and volume in the first 30–60 days post-launch — so there’s something concrete to hold the grant against?
Thanks!
Hi @bradvani following up on my last question. Can you please provide liquidity data across the DEX ecosystem for each asset pair that you plan on supporting? Thanks.
Hey @Axia thanks for your question. For the initial rollout, we’re planning to support all major stablecoin pairs, blue-chip assets and any additional assets recommended by the Rootstock team.
We’ll aggregate liquidity across the following DEXs and aggregators:
OpenOcean
EisenFinance
SushiSwap
Meson
Nordstern Finance
DZap Aggregator
Thanks @dzap @bradvani for the detailed answers so far; the metrics and architecture clarifications are helpful. A few additional points that could strengthen the proposal:
-
Atomicity/failure handling: Since the swap and stake are batched into one transaction, what happens if the swap leg experiences excessive slippage or fails mid-execution? Clarifying rollback/revert behaviour and any slippage protection would help assess user-fund safety.
-
Milestone clarity: Only Milestone 1 has a specific budget ($1,350 of $4,500). It would help reviewers if Milestones 2 and 3 had defined deliverables, timelines, and dollar amounts tied to measurable KPIs before funds are released for those stages.
-
Discoverability: Will the one-click staking flow be surfaced within RootstockCollective’s own staking interface/dApp, or only on DZap’s site? This affects how much of the projected adoption is actually reachable by existing RIF holders.
Thanks. To clarify, I was hoping that you could share liquidity data on each pair. Because it’s important that there is enough liquidity to make the swap possible.
Sure @Axia let me elaborate as the liquidity data for each pair is dynamic at different times:
DZap does not manage any liquidity. We are an execution layer built on top of existing DEX Aggregators, who by themselves also aggregate liquidity and do not manage it themselves. The data of pairs completely depends on the venues themselves, i.e. the list shared above. To keep it simpler, as long as there is any present DEX liquidity, anywhere on-chain, for any pair, it can be supported.
So replying to the question is not in scope as it demands real-time tracking of dynamic DEX liquidity across all venues indexed and integrated for Rootstock, which is also variable as the ecosystem grows.
Please take a look at this page from our docs to establish a better understanding of our execution flow:
Hey @krngill it’s my pleasure, thank you for your review on the proposal and appreciate your thoughtful feedback.
Happy to address the points raised:
-
Atomicity/ Failure handling: Since we have built an intent execution engine above existing aggregators. There is a binary output on the entire end-to-end flow of the swap+instruction. i.e. either the funds are still in wallet, or converted to staked RIF, there is no in between. If in case there is a slippage issue and the funds are deducted on source, the RIF will be received on destination chain.
-
Milestone clarity: The Milestone 1 is the indexing of the protocol which is already complete as mentioned in point no. 4 of the proposal, point no. 5 is the execution engine which is customising the instruction after the asset swap. This tech lift would take under 14 days away from going live after our proposal is passed and includes tracking the metrics on a public dashboard for ecosystem analysis on broadening chain/asset support. (note point no. 8 - on the proposal).
-
Discoverability: This is a crucial element which would be far more effective on RootstockCollective’s own interface as it is the primary location for user interaction. By eliminating friction and reducing user steps on the collective website we can estimate a decent increase in staking/volume activity and also make better collaborative decisions of further execution implementations within the ecosystem.
@dzap RIF staking is one of the bigger priorities for the Collective right now, so proposals that make it easier to get into are welcome. We also agree with the point raised in the thread that this becomes much more compelling if it sits inside the RC interface rather than only on dzap.io, since that’s where people already go to stake and it would make the whole experience a lot more meaningful.
DZap has been building on Rootstock since early 2025 and has a live product with real usage, so at this size we’re leaning supportive, but with a few caveats. We think this needs to be polished before going on-chain. A few structural considerations/suggestions:
On Substitution versus new staking:
The 70 to 80 percent figure describes share of flow rather than growth. If most of that turns out to be existing holders switching to a better route, staked RIF stays flat and the DAO is paying for a smoother journey rather than more staking. Both are worth funding at this amount, they’re just different outcomes, and the dashboard should let us tell them apart. Net new staking wallets and net new RIF staked over the first 60 days would cover it.
On The RC interface placement still being an open dependency:
Following on @krngill’s question, the answer reads more like a preference than a plan. The 90 percent first-time staker projection depends on the flow being where first-time stakers actually land, and that placement isn’t in the scope, the two week timeline, or committed by anyone yet. We’d suggest treating it as something still to be worked out with the team, and it would help to see what the numbers look like if the flow launches only on dzap.io.
On Milestone structure:
Given the build is about two weeks, three milestones may be more than the work needs, and as written the first tranche pays for indexing that’s already finished. A simpler split could be one tranche when the flow is live and verified on mainnet, and the rest 60 days later against the dashboard numbers. That keeps a real checkpoint at the end instead of releasing everything before there’s anything to measure, and it gives the team a clean way to show the integration did what it says.
Hey @ChronoTrigger, thank you for your thoughtful review and for the supportive signals shown, really appreciate the careful read. Happy to address each point:
On Substitution vs Net-New Stakers
This is a fair and important distinction and you’re right that the dashboard should make it legible. We’ll track and separately report:
- Net new unique wallets staking (first-time stRIF holders)
- Net new RIF staked through DZap flows (regardless if previously staked by that wallet)
- Token Usage as per routing preferences for conversion to stRIF
This gives the Collective a clean read on the integration and can grow or improve the staking base for new users and enhance the journey for existing holders; both are measurable, both are worth collecting. We’ll surface these as distinct metrics in each monthly report from day one.
On milestone structuring
We’d respectfully push back on restructuring M1. Milestone 1 was protocol indexing and is already complete. That work has been delivered, verified and represents real engineering effort against a defined deliverable.
Holding payment for completed work contingent on future metrics would set an unusual precedent for grant structures where early stage technical groundwork is a prerequisite for everything that follows.
The current structure already has a real checkpoint: M2 and M3 release against product delivery and chasing live metrics respectively. We’re open to tightening the KPI definitions on M2 and M3 if that would give reviewers more confidence and open to track deliverables/ on-chain verification criteria for both tranches.
On RootstockCollective interface placement
We’ve raised this directly with the Rootstock team too. Their position is that interface placement would be subject to delegate decisions, which we understand and respect, it’s not ours to commit unilaterally. We wanted to flag that clearly rather than treat it as a given, so would truly appreciate the votes.
In the meantime, here’s what the numbers look like with a DZap only launch baseline:
- Super conservative 30-day estimate: 50–80 unique wallets, $15K–30K in staking volume routed via DZap
- These projections are intentionally modest, scoped to organic discovery and any co-marketing with the Collective.
- Native interface integration, if approved by delegates, would be certainly north of our above baseline estimates.
We think this is the honest framing, the launch is the deliverable within our control, RC integration is the upside we’re actively pursuing through the right channels.
Happy to get on a call with the Collective if it helps move forward discuss the native UI installation details. Trust this caters to all points raised.
Thank you!
Me gustaría sumar un par de puntos al análisis de esta propuesta, mirando la lógica de los números y los riesgos para el Collective de forma independiente:
1. La eficiencia del capital
Si miramos las proyecciones que compartieron para el lanzamiento solo en su web (de $15k a $30k USD en volumen de staking el primer mes), un grant de $4,500 USD significa que la DAO estaría subsidiando entre el 15% y el 30% de todo el capital que se mueva por ahí. Financieramente, pagar ese porcentaje por un volumen tan bajo en una plataforma externa no hace mucho sentido para la tesorería. Para que este gasto se justifique, el desembolso del último hito (M3) no debería liberarse solo por “armar el dashboard y medir datos”, sino que tendría que estar atado a que realmente alcancen ese piso mínimo de volumen que prometen.
2. Desequilibrio en los hitos y el riesgo
Hay una asimetría clara en cómo se reparten los riesgos aquí. Se nos pide pagar de entrada el Hito 1 por un trabajo de indexación que ya está hecho, pero todo el riesgo de si la dApp se usa o no en el futuro se le deja a la DAO. Si el Collective va a reconocer el trabajo de ingeniería ya entregado, el equipo también debería comprometerse con el mismo nivel de exigencia para lo que viene. Creo que no deberíamos pasar esto a votación on-chain hasta que los hitos futuros (M2 y M3) dejen claro, con números específicos, qué volumen de transacciones o retención de depósitos se necesitan para liberar los fondos restantes.
Love seeing teams focus on making Rootstock easier to use.
Hi all!
We want to flag that the on-chain proposal have been submitted incorrectly, as it requests the transfer of 1,350 rBTC instead of 1,350 USDRIF. For this reason, we voted against the proposal and we would like to request to the proposer to resubmit the proposal correctly once the current voting period has ended.
Regarding the substance of the proposal, we agree with @ChronoTrigger and @LEGOSI that the final milestone payment should not be contingent solely on the technical delivery of the product. In accordance with the Grant Guidelines, the proposal should also include verifiable on-chain impact metrics and the final payment should be conditional on meeting previously established KPIs, to ensure that, beyond being technically functional, the product has achieved sufficient traction to generate a reasonable ROI on the funds allocated.
Until appropriate, verifiable on-chain KPIs are included as a condition for the final payment and provide a basis for assessing the ROI of the funds allocated, we will vote against this proposal.
I have some concerns about the proposal in its current structure, particularly around capital efficiency and the allocation of risk between the Collective and the team.
Based on the projections shared for the launch on their website, with an expected $15k–$30k in staking volume during the first month, a $4,500 grant would effectively represent 15%–30% of the capital expected to flow through the platform. From a treasury-efficiency perspective, that seems difficult to justify for a relatively limited volume on an external platform. For the grant to make economic sense, the final milestone (M3) should not be released simply for building a dashboard and reporting the resulting data. It should instead be contingent on achieving a clearly defined minimum staking volume or other meaningful adoption target.
There is also an imbalance in how the risk is currently distributed. The proposal asks the Collective to fund M1 for indexing work that has already been completed, while the risk associated with whether the dApp actually achieves meaningful adoption remains largely with the DAO. If the Collective is willing to recognize the engineering work already delivered, the remaining funding should also be tied to measurable outcomes and accountability from the team.
Before taking this proposal to an on-chain vote, I believe M2 and M3 should be revised to include specific and quantifiable targets, such as minimum transaction volume, number of unique staking wallets, or retained deposits. The remaining funds should only be released once those targets are achieved. This would create better alignment between the grant amount, treasury risk, and the actual value delivered to the Rootstock ecosystem.
@bradvani thanks for putting real numbers out, we’d rather have an honest baseline than a flattering one. That said, as @pranavkonde pointed out, the scale is the issue. There’s around 32.9M stRIF staked today, $2.67M, against a circulating market cap near $81M. A first month of $15K to $30K routed volume lands at about half a percent to one percent of what’s already staked, which is close to a rounding error. A few of us have also asked for clearer KPIs on M2 and M3 and those still aren’t written up.
Being upfront about where this stands, even with the currency corrected on the on-chain submission, we don’t think the proposal passes in its current shape. Some community members have said as much in the thread already, and we’d suggest avoiding rushing a resubmission that would likely fail.
Where we’d focus is raising the baseline.
Sorting out the integration into the RootstockCollective dashboard looks like the only path that really gets there, since discovery through dzap.io alone may never reach the traction this needs to justify itself. Worth reaching out to the Rootstock Collective side to get that commitment settled, and thinking through for other ideas to lift the projections before the next submission.