[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?

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.

92

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