-
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.