[2601 Grant] SwaptoX Aggregator – Milestone 1

Grants & Incentives
82

@Axia Thanks for the update, really appreciate it!

1 Like
83

GM - please write to us directly via telegram, we need to make some additional requests : @tamaralerner

Thank you

1 Like
84

Milestone 2 Extension and Scope Adjustment Request

According to the original Milestone 2 schedule, the delivery date is June 15. Unfortunately, I will not be able to complete all planned deliverables by that date and would like to request a short extension.

Completed Work

:white_check_mark: Governance Upgrade for Routing Contracts

  • Multi-admin support

  • Timelock governance integration

:white_check_mark: Audit Preparation

  • Contacted approximately 10 security audit firms

  • Received around 7 audit quotations

  • Evaluated scope, pricing, and timelines for the upcoming audit

:white_check_mark: swaptox-connect (Additional Deliverable)

This component was not originally included in the milestone scope.

Repository:

swaptox-connect is a wallet connectivity SDK developed to serve multiple parts of the SwaptoX ecosystem, including:

  • SwaptoX DApp

  • Mobile Mini DApp

  • Admin Dashboard

  • SwaptoX Timelock Administration Interface

We believe that combining swaptox-connect with swaptox-widget significantly reduces integration complexity for third-party developers. The component can be used independently or together with swaptox-widget.

(Previously referred to as Mini-SDK. The project has since been renamed to swaptox-widget.)

In Progress

The following items are closely related and will be completed together:

  1. Split Routing Engine

  2. USD Pricing Logic Upgrade Based on Split Route Quoting

  3. Full API Migration to Redis-Based Caching

Requested Scope Adjustment

The following items are primarily UI-related features:

  • Transaction History Display

  • Permit-Based Approval Support

  • Route Display Redesign

Because these features belong to the presentation layer and depend on the final routing architecture, I would like to move them to Milestone 3, which already focuses on SDK and Widget UI development.

This adjustment would allow all Widget/UI-related work to be delivered together within a more coherent development phase.

Reason for Extension

The primary reason for the delay is that the complexity of implementing a competitive split-routing system was significantly higher than originally estimated.

The initial design assumed that order splitting would occur only across independent routes.

However, during research and implementation, it became clear that mature aggregators such as OpenOcean utilize tree-based routing structures, where liquidity can be split recursively at multiple routing levels.

                        PoolA
                Pool  │
                        PoolB

        Pool  ──│

                        PoolC
                Pool  │
                        PoolD

ROOT ──│

                        PoolE
                Pool  │
                        PoolF

        Pool  ──│

                        PoolG
                Pool  │
                        PoolH

As a result, the original architecture was insufficient to achieve competitive routing quality and quote accuracy.

To address this, substantial additional research and redesign work was required.

Technical Progress

After evaluating multiple routing approaches, we finalized a tree-based split-routing architecture.

To avoid excessive RPC computation costs, the system uses route sampling and interpolation techniques to estimate intermediate pricing points and search for near-optimal route combinations efficiently.

The resulting route is then validated through on-chain simulation to obtain accurate output amounts, gas estimates, and execution verification.

During this process, we also evaluated several simulation approaches and ultimately finalized a solution based on stateOverride and flash-loan-assisted simulation.

This architecture provides near-complete coverage for tradable assets on Rootstock while maintaining practical performance and infrastructure costs.

Current Status

The tree-based split-routing calculation engine has already been implemented and is producing routing results.

Remaining work includes:

  1. Split-route execution validation engine

  2. Route output verification and simulation pipeline

  3. stateOverride + flash-loan simulation integration

  4. Redis migration finalization

  5. End-to-end testing and optimization

Extension Request

Based on the progress achieved and the remaining implementation work, I would like to request an extension until June 30, 2026.

The technical direction has already been validated and the remaining work is primarily implementation, integration, and testing.

I would also appreciate feedback regarding the proposed scope adjustment of the UI-related features to Milestone 3.

Thank you for your consideration.

2 Likes
85

We are certainly not speaking on behalf of all the delegates, but only for ourselves; however, the reasons given are entirely reasonable (we appreciate the detailed explanation), as is the request to provide all deliberable works together relating to the UI. Therefore, we consider it entirely reasonable to grant a 15-day extension, which, moreover, causes no harm whatsoever.

1 Like
86

Thanks for the detailed update, @SwaptoX. Tree-based recursive splitting is a genuinely harder problem than splitting across independent routes, and @SEEDGov is right that the reasons hold up: no objection to the 15-day extension, and moving the UI work into the M3 widget phase is sensible.

One item for M2 delivery. When we flagged audit planning, the M2 deliverable became a concrete audit plan with a selected provider, locked scope, cost, and timeline, plus the third-party grant applications, not just quotations. Contacting around ten firms is progress, but the finalized plan is the deliverable.

So at delivery, could you share three things: the finalized audit plan; the deployed multisig and timelock addresses, so the governance upgrade can be verified on-chain; and the public split-routing comparison page against OpenOcean that the scope set as the validation mechanism?

1 Like
87

Glad to have news from this project.

No objection to the 15-day extension at all. Tree-based recursive splitting is a real step up from independent-route splitting.

Moving the UI work into the M3 widget phase is reasonable, as long as it carries over as actual M3 deliverables and doesn’t later become grounds to grow that milestone’s scope or budget.

Since M2 was funded at approval, the meaningful checkpoint now is M3, and I’d treat the M2 deliverables as the conditions for it. The one that matters most is the public comparison page against OpenOcean, held to the methodology and success criteria you set yourself in the revised scope, thirty-plus scenarios across trade sizes and pairs over multiple blocks, judged on median and large-trade behavior rather than a few favorable quotes. That page is what proves the split-routing work was worth the milestone, and it’s the concrete form of the verifiability point I raised earlier. Alongside it, the deployed multisig and timelock addresses for on-chain verification, and a finalized audit plan with a selected provider, scope, cost and timeline, not just the quotations gathered so far, which is the same thing @Tane flagged.

2 Likes
88

Hey @SwaptoX thanks for continuing to build. If I understand correctly, you are also creating a DAO to govern the dApp?

1 Like
89

Thank you all for the feedback and support.

@Tane , @Chronotrigger ,

I understand the requirements for the final M2 delivery. The key deliverables remain aligned with the approved scope: the audit plan, multisig + timelock governance upgrade, and split-routing implementation.

For the split-routing milestone, I will provide a public comparison page against OpenOcean together with a detailed explanation of the methodology and results.

The UI-related items are being moved to Milestone 3 purely to accelerate the delivery of Milestone 2. They will remain part of the project roadmap and this adjustment will not be used as a basis for expanding the scope or budget of M3.

Regarding the audit plan, selecting a preferred audit provider is not difficult. However, there are significant differences between providers in terms of audit depth, review duration, reputation, and cost (ranging from roughly $3k to $15k). Because audit funding was not included in the original milestone budget, I believe the final audit engagement should be discussed and aligned with the committee before being finalized.

For the M2 delivery, I will provide a recommended audit provider, proposed scope, estimated cost, timeline, and the rationale behind that recommendation.

@Axia ,

SwaptoXTimelock is not intended to be a DAO. It is a multisig + timelock governance mechanism designed to reduce the risks associated with a single administrator key being compromised or lost, while improving transparency around protocol changes.

90

Hey @SwaptoX , thanks for the update and the clarification on the timelock mechanism. On the audit front: it is understandable that you don’t want to finalize a $15k contract without the budget to back it up. Can you help us clarify if you expect the DAO to fund this audit via an additional grant request, or are you planning to cover it within your existing allocations?

1 Like
91

Hi @SwaptoX the audit is a very sensitive topic given that this is a DeFi product that will interact with user funds. We echo the questions that have been raised and would like to ask if you could clarify and provide details on how you plan to handle the security audit, particularly with regard to funds and timing.

1 Like
92

@SwaptoX thanks for clarifying about the multisig + timelock mechanism. Who do you intend to be the signers on the multisig?

1 Like
93

Hi @SwaptoX

Thanks for the information. We read your message for an extension when you posted it and understood it more as an update than as a request. Since M2 funds had already been released, it leaves limited room to act, however we appreciate the transparency as it helps to mitigate a negative perception of missed deadlines and future delivery commitments.

On audit costs
We agree an audit is necessary and are trying to understand what is fair regarding funding it. It bears directly on how we think about Rootstock’s role as the initial funder and what the Collective gets in return.

On parallel ecosystem interest
Earlier in this thread, SwaptoX stated: “SwaptoX needs to establish trust and market share within a specific ecosystem before considering multi-chain expansion… We aim to gain our first core user base and market share here on Rootstock before considering other plans.”

Nonetheless, we observed that in April 2026 — SwaptoX communicated to the Conflux Network forum that Rootstock is funding the core SDK and API work, and that Conflux would receive a fuller proposal once those milestones are complete.
[ SwaptoX Aggregator – Relocation & Ecosystem Integration Proposal (Conflux Network) - Grant Proposals - Conflux Forum ]

We’d welcome your perspective on the path to growth and self-sufficiency, and what Rootstock’s role as initial funder looks like relative to ecosystems that would benefit from that investment later or the credibility that an audit generates.

These are open questions and observations and look forward to your input.
Thank you!

1 Like
94

Hi @SwaptoX
The open question that keeps circling back is the audit, and I think it is worth naming why it feels unresolved rather than just asking again who pays. The stated sustainability model is protocol swap fees that scale with volume. But fees only get switched on after Entered is open sourced, and the contract handling funds mid execution is exactly what the audit is meant to cover. So the audit is not a side cost bolted onto the grant, it sits right on the path between today and the point where the project funds itself. Treating it as a separate future grant request slightly hides that. It would help to see the audit framed as part of the core deliverable chain, with a clear position on whether the DAO is being asked to fund it, partly fund it, or wait on the Optimism grant, rather than leaving it open.

On the M2 delivery items, the public comparison page against OpenOcean is the one I would weight most, and I would hold it to the methodology already set: many scenarios across trade sizes and pairs over multiple blocks, judged on median and large trade behaviour. That page is what actually settles whether the split routing work earned the milestone, since the report itself conceded OpenOcean wins on larger swaps. A handful of favourable quotes would not answer it.

The responsiveness through this thread has been real, and the governance redesign into a timelock is a genuine improvement.

1 Like
95

Sorry for the delayed response — I’ve been fully focused on completing the current milestone work.

I’ll address @Axia briefly first:

At the moment, I’m operating as a solo developer. All three admin keys are currently held by me. In the future, once a team is formed, I will consider distributing governance/control rights accordingly. I’m also open to any suggestions you may have on this structure.

Regarding the transaction-splitting work:

The API has already been deployed to the server today. However, I still need approximately two days for testing, plus one additional day to build a public-facing comparison page.

Therefore, I will submit the full report within 3 days, before July 3rd.

A preliminary note:
In most of our tests, our results outperform OpenOcean. This is primarily because OpenOcean’s outAmount field is not always accurate.

We do not rely directly on the API-provided outAmount. Instead, under the same slippage condition, we compare based on the minOutAmount returned by the API.

minOutAmount represents the theoretically guaranteed minimum output (i.e., worst-case protected output), rather than the expected optimal outAmount.

That said, minOutAmount is still not fully trustworthy on its own. I will introduce a more reliable verification approach:

We will send the API-returned data to a third-party RPC simulation environment and re-execute the swap to validate the actual outAmount. This simulated execution result will be treated as the most reliable benchmark.

Within 3 days, I will deliver both:

  • a comparison dashboard
  • a trustworthy verification methodology

I will also consolidate and respond to the remaining questions after that.

96

Perhaps the auditors can help you think through the structure. In general, I think you should think create a progressive decentralization roadmap with a DAO on the roadmap, as the protocol matures.

1 Like
97

This is an important observation and question that @DAOstar_gov made. Please address this question before submitting your Milestone 3 proposal. Also, are there other ecosystems we should be aware of where you submitted a grant proposal?

1 Like
98

Split Trade Comparison Page Description

This update is still in a non-final state, but it is already functional for comparison purposes. Feedback and suggestions are welcome.

1. Comparison Principle

This page compares quote quality across different aggregators using three key metrics:

  1. Retrieve from API:
    • AmountOut
    • AmountMinOut
    • Route data
  2. Send route data to a smart contract for on-chain simulation execution
  3. Obtain simulation results via a third-party RPC (with state override support):
    • RealAmountOut

Ultimately, the system compares the following three values:

  • AmountOut
    • Source: API response
    • Nature: Pre-execution quote (not a final on-chain result)
    • Reliability: Low
  • AmountMinOut
    • Source: Platform calculation
    • Meaning: Minimum acceptable output (transactions revert below this value)
    • Nature: Slippage protection value, more meaningful for reference
  • RealAmountOut
    • Source: RPC simulation execution result
    • Condition: If liquidity does not change in the next block, this can be treated as the actual execution output
    • Reliability: Highest

2. Previous Verification Architecture

The SwaptoX execution path is based on a custom executor contract:

This simulation contract has the following characteristics:

  • Supports both SwaptoX and OpenOcean executors
  • Each route execution is immediately reverted to ensure a clean simulation state
  • Enables simulation execution via RPC state override, allowing virtual fund injection without real transfers

3. Comparison Rules

Using AmountOut as an example:

  • SwaptoX vs OpenOcean are compared directly
  • The higher output value wins 1 point
  • If equal, no points are awarded to either side

The same scoring logic applies to AmountMinOut and RealAmountOut.

4. Result Analysis

1. Why OpenOcean Often Shows Higher AmountOut

In most cases, OpenOcean’s AmountOut appears slightly higher.

This is mainly because:

  • OpenOcean applies an additional ~0.1% adjustment on top of the user-defined slippage
  • This inflates quoted output values
  • It may be related to its fee or routing mechanism
  • The effective fee model appears dynamic rather than fixed

2. Performance on Base Network

On Base:

  • SwaptoX win rate is approximately 70%–80%
  • Main reasons:
    • SwaptoX currently does not charge fees
    • OpenOcean appears to include implicit fee/slippage adjustments (~0.1%)
  • In a liquidity-rich environment, these results are relatively representative

3. Performance on Rootstock

On Rootstock:

  • SwaptoX win rate is approximately 50%–60%
  • Key factors:
    • No fees on SwaptoX side (advantage)
    • However, certain tokens show significant discrepancies

Further investigation revealed:

  • Sovryn has multiple liquidity versions
  • Some of these are not exposed in the official DApp or standard interfaces
  • OpenOcean integrates a more complete set of Sovryn liquidity sources
  • This leads to noticeable differences for specific trading pairs

5. Next Optimization Plan

Within the next 2–3 days:

  • Integrate missing Sovryn liquidity sources
  • Improve SwaptoX routing coverage
  • Enhance quote accuracy on Rootstock

After completing the integration of the missing Sovryn liquidity sources, I will proceed with the formal Milestone 2 delivery as planned.

6. Comparison Page Notes

This is a single-page tool. You can inspect logs in the browser console and review the source code for auditing purposes.

屏幕截图 2026-07-03 230736
屏幕截图 2026-07-03 2307361522×630 59.6 KB

99

Milestone 2 Delivery Report

Milestone 2 primarily covers split routing (split trading execution), multi-admin timelock, and audit quotation & planning.
Other UI-related components have been moved to Milestone 3.

1. Multi-Admin & Timelock

Reference discussion:

The multi-admin and timelock mechanism has been described previously.

However, it has not been deployed yet for the following reasons:

  • The design may still require adjustments before audit.
  • The fee parameter is under reconsideration. I believe a maximum cap of 0.2% is sufficient, compared to the original 0.3%, which I consider slightly high.
  • At this stage, deployment would not be suitable for demonstration because split routing has changed significantly, and the frontend routing logic still needs to be adapted accordingly.

2. Split Routing / Split Trading

The original requirement was that for large trades, SwaptoX should show no significant difference compared to OpenOcean. Based on the test results provided in the previous report:

  • Overall win rate: ~70%–80%
  • After applying a 0.1% fee deduction for fairness, the win rate remains around 60%–70%

From this perspective, SwaptoX does not show a clear disadvantage compared to OpenOcean, but rather each system has different strengths.

For example:

  • In 1 BTC → USDT / USDC, SwaptoX generally achieves better output
  • In 1 BTC → RIF / USDRIF, OpenOcean tends to perform better

However, this is not absolute. In some cases the results can reverse, especially for trades below 0.1 BTC, where more fluctuation appears:

  • sometimes SwaptoX performs better
  • sometimes OpenOcean performs better

Overall, SwaptoX performs slightly better in aggregate due to:

  • wider token coverage
  • stronger route diversity

On the other hand, OpenOcean shows higher variability in large trade routing, and in some cases their quoted result can be non-executable (simulation output is zero), meaning the route cannot be executed on-chain even though it can be quoted.

This kind of inconsistency is not always visible on-chain because wallets often filter out failing routes before execution.

Fee-adjusted comparison links:

Split Routing Algorithm Design & Interpretation

After a deeper understanding of split routing mechanisms, I believe that finding better routes than OpenOcean is not fundamentally impossible. Under the assumption of identical liquidity conditions, if we expose a sufficiently deep search for route computation, it is likely to discover better output paths. Even a 0.1% change in split ratio can potentially lead to a better result in some cases.

However, this must be balanced with computation cost and performance constraints. If a quote requires full-chain liquidity graph evaluation, the latency would become too high for practical use cases, making real-time quoting difficult.

Therefore, in order to optimize performance, routing systems inevitably apply filtering and pruning strategies on available liquidity data. This is also the reason why different systems may produce different results — sometimes one performs better, sometimes the other does.

This is the first version of our split routing design, and it still has room for improvement. With continuous iterations, we expect the routing quality and efficiency to further improve.

Audit Quotation & Planning

It has now been nearly two months since the initial audit quotation request. I will provide a consolidated update on audit progress and next steps in the following report.

1 Like
100

Thanks for the delivery report, @SwaptoX. The comparison infrastructure is good work: on-chain simulation instead of quoted outputs is more rigorous than most aggregator comparisons, and finding that some OpenOcean quotes cannot actually execute is a real result.

Two gaps keep us from treating M2 as closed.

First, the validation does not follow the protocol in the revised scope, the same bar @ChronoTrigger and @krngill have pointed to: thirty-plus scenarios across varying trade sizes and pairs, over multiple blocks, judged on average, median, and large-trade behavior. We read the page source; it runs a single pass at one trade size. The report’s overall win rate of 70-80% is also not the Rootstock number; your earlier results put Rootstock at 50-60%, before the Sovryn liquidity work you said would follow. Please run the committed protocol on Rootstock, fee-adjusted, and post the statistics.

Second, the multisig and timelock are not deployed, and deployed, verifiable addresses were part of the M2 delivery conditions. Your reasons for waiting are on record: possible design changes before the audit, the fee cap under reconsideration, the frontend still adapting. If that is the plan, then state it in the milestone record: the governance upgrade and the 2028 fee lock move to M3. Note the fee cap is the parameter the timelock is meant to lock; until a contract is live, that commitment cannot be verified.

On the audit, we share the funding and timing questions other delegates have raised.

1 Like
101

The on-chain simulation methodology in the M2 comparison work deserves credit, since judging aggregators on simulated executable output rather than quoted numbers is more rigorous than standard practice, and surfacing quotes that cannot actually execute is exactly the kind of result that justifies the approach. On the validation gap we will not restate what @Tane, @ChronoTrigger, and @krngill have already laid out, other than to say we agree the committed thirty-plus scenario protocol, run fee-adjusted on Rootstock, is the right bar for closing M2, and the Rootstock-specific win rate is the number that matters for this grant. The point we want to add is on the audit line item: since M2 includes audit quotation and planning, and the admin model was redesigned mid-milestone into the multi-admin timelock structure after the 24KB contract size constraint forced router changes, we would want confirmation that the audit scope and quote reflect the final architecture rather than the earlier single-owner design. An audit priced against superseded code would leave the actual deployment surface unreviewed at exactly the layer that was just restructured. Could you confirm the quotes you gathered cover the redesigned contracts, @SwaptoX, and whether the prospective auditors have been told the admin model changed?

1 Like