[2601 Grant] SwaptoX Aggregator – Milestone 1

SwaptoX is an existing product that has been live on Base for over four months.
Milestone 1 therefore focuses on verifiable migration and deployment outcomes rather than a greenfield build.

Milestone 1 – Verifiable Acceptance Items

  1. Contract deployment on Rootstock mainnet
    The core SwaptoX smart contracts, including the swap execution contract and the quote/pricing contract, will be deployed on Rootstock mainnet.
    Verification can be completed by checking the published contract addresses.

  2. Frontend and backend integration with Rootstock data
    The SwaptoX frontend UI and backend services will be integrated with Rootstock-native token and pool data.
    Reviewers can verify this directly via the SwaptoX application interface.
    Additionally, an admin-side walkthrough video can be provided to demonstrate backend configuration and data integration if required.

  3. End-user swap execution on Rootstock liquidity sources
    Users will be able to execute token swaps on the SwaptoX application using liquidity from WoodSwap and Sushi on Rootstock.

    A demonstration video showing swap execution on Base mainnet is provided as a functional reference.
    Upon completion of the migration, equivalent demonstration swaps on Rootstock mainnet will be provided, such as:

    • Swaps involving WoodSwap liquidity

    • Swaps involving Sushi liquidity

demo video:https://youtu.be/9R1VgnL2XCE?si=xJ7CYrVsy_izVWB4

Due to the KYC process not being fully completed before submission, I submitted the on-chain proposal without fully following the required procedures. I deeply apologize for any inconvenience caused by this oversight.

However, prior to submitting the on-chain proposal, I had already provided the address verification documents via email. I was under the impression that KYC would be processed soon, and I hoped to expedite the process by submitting the proposal together with the KYC verification. Unfortunately, this led to the failure to adhere to the proper governance process.

For the past two weeks, I have been waiting for a response regarding my KYC status, but I have not received any updates. I would appreciate it if you could kindly provide an update on the status of my KYC process, whether it is still ongoing, or if there are additional materials required. Thank you for your assistance.

hey @SwaptoX I’ve flagged this topic about KYC request to the Collective admin, so they can look into it directly. I’m sure there will be a return from them soon.

As I mentioned in my voting rationale, the product being live on Base for 5+ months now is a strong testament to this project, and for me this weighs significantly toward supporting a future grant request.

That said, as others have noted, there are still pending concerns around differentiation vs existing aggregators, solo developer sustainability risk, lack of third-party audits, and the need for more concrete verifiable milestones.

I just want to say I sincerely hope these can be addressed, KYC completed, and a fresh proposal submitted.
Maybe in a future proposal, you can bring more detailed statistics and metrics on this project’s Base usage.

GM @SwaptoX

Your KYC verification has been approved by our internal compliance team.

To clarify the timeline: our KYC request was sent on January 29th, 2026 – over two weeks ago. The delay in response appears to be on your end. As standard practice for all grant applicants, it is your responsibility to monitor all email communications, including spam folders, particularly during active application processes.

The additional documentation requirement is not exceptional – it is part of our established compliance framework that all grantees must complete.

Moving Forward:

  • Milestone 1 deliverables will proceed to evaluation

  • Future communications require timely responses to maintain disbursement schedules

  • All subsequent milestones follow the same verification protocol

We operate on strict operational timelines. Please ensure consistent monitoring of communications from our team to avoid processing delays.

Best regards!

1 Like

I am pleased to have received the notification that my KYC has been approved. I would also like to express my sincere gratitude to everyone who voted for my proposal and provided valuable comments.
I have reviewed all of your feedback, and while I am unable to respond to each comment individually, I will now provide a unified response addressing the key concerns.


1. Verifiability of SwaptoX

Currently, there are 155 wallet-linked users on Base, and 130 transactions have been completed.
The project is still in the Beta phase, with a focus on technical validation rather than large-scale user acquisition.


2. Differentiation of SwaptoX from OpenOcean and Ecological Complementarity

  • Major aggregators, due to listing policies and brand risks, will not support many obscure tokens now or in the future.
    SwaptoX has no such brand risk, and our position is to support more tokens. As such, we will actively integrate and maintain a wider variety of tokens.
    Tokens that users cannot find on OpenOcean may be easily exchanged on SwaptoX.

  • Verification method: Open both SwaptoX and OpenOcean websites, select the Base network, and compare the token lists.
    Result: SwaptoX supports over 600 tokens, while OpenOcean currently supports fewer than 200 tokens.

  • Support for precise output functionality: Many aggregators do not support this feature, which is one of the differentiating factors for SwaptoX. Further clarification on the audit section is provided below.

  • Visible differentiation:

    • Multi-language support: This includes Asian languages such as Chinese, Korean, and Japanese, making SwaptoX particularly user-friendly for the Asian market.

    • Routing selection: SwaptoX displays multiple routing options and provides a price comparison for users to choose from, clearly indicating which route offers the best output.

  • SDK Differentiation:

    • OpenOcean SDK is a JavaScript library that wraps many commonly used functions, but it does not include UI components.
      More details: OpenOcean SDK Documentation

    • SwaptoX Mini SDK (with “Mini” referring to the Mini UI version) is a complete swap UI library, including full UI interactions, allowing for quick integration of exchange functionality.

  • Token exchange scenarios are common: For other DEXs, achieving optimal output with simple fixed-route swaps is difficult, and developing a custom aggregator is not an easy task. Integrating SwaptoX Mini SDK is a cost-effective solution. Additionally, at the time of our launch, we had already implemented a referral reward feature, where developers using the Mini SDK for token swaps can earn additional transaction fees.
    More details: SwaptoX Referral Program

  • Mini SDK development:
    We are already actively working on the development of Mini SDK.

    SwaptoX Mini UI

3. Verifiable Results of Milestone 1

  • Once completed, users can access SwaptoX at https://app.swaptox.com/?chain=rootstock (or switch to the Rootstock network in the top-right corner).
    Users can link their wallets and perform token swaps, with 1-3 routing options displayed, showing liquidity sources from WoodSwap or Sushi, or both.

  • During the swap process, users will see the on-chain swap address (swapAddress). After Milestone 1 is completed, I will also provide the contract addresses for deployment.

4. Regarding Solo Developer

I understand the importance of having a team, but due to resource constraints and priority issues, it is not yet suitable for me to form a team. However, we plan to begin assembling a small team in the next 6 months.
I have been working full-time on SwaptoX for over a year. The project originated from my previous arbitrage system, and it was not developed with the goal of winning competitions or awards but as an organically evolving project.
The journey from “tactics” to “abstraction” to “SwaptoX” has not been easy for me. I have invested a significant amount of time and money, driven solely by my trust in and passion for decentralization.
Therefore, no matter the challenges, I will not easily give up on this project.

I consulted with three AI experts, and the estimated development cost of SwaptoX as an aggregator exceeds $80,000.
For more details, here is the consultation link: AI Consultation Link
As we progress with the milestones, the cost and value of SwaptoX will continue to rise. Even if I am unable to continue, there will certainly be teams willing to take over and continue running the project.
Building an aggregator is not an easy task for any team—it requires not only money but also time.

5. Regarding Audit

I understand the importance of audits, but at this stage, the priority for auditing is relatively low, for the following reasons:

  1. SwaptoX does not hold user funds, which significantly reduces security risks.

  2. We believe SwaptoX is still evolving, and we’ve already made three updates to the swap contract, not due to security issues but to add and optimize features.

Once the above 3 milestones are completed, we plan to spend the next two months developing advanced features and upgrading smart contracts, such as limit orders and precise output functionality.
Although these features are optional, we plan to implement them to enhance SwaptoX and provide differentiation.

6. Precise Output and Limit Orders

Precise output is a feature that most aggregators do not support, but it is essential for use cases like online payments. We believe this feature is crucial for SwaptoX’s future development and for our Mini SDK.

Thank you @SwaptoX.

You write:

I understand the rationale for supporting long-tail assets, but user safety should remain the top priority. Have you considered implementing safeguards like a reputation score for tokens or a curated verified list to help users identify potentially fraudulent assets?

Additionally, users should have easy access to real-time liquidity information for each token. This would help prevent issues like receiving the wrong token in their wallet or experiencing unexpected transaction reversals due to insufficient liquidity.

@axia

Yes, we plan to provide certification identification for popular tokens. The relevant functionality has already been developed on the backend, but the DApp has not been updated yet.
Of course, we will also provide liquidity information for tokens. In the next phase, our DApp will list both popular representative tokens and liquidity information.

At the same time, we are considering providing information on the price gap for token buying and selling. For example, if the buy price is 0.1 USD and the sell price is 0.08 USD, a warning will be displayed if the price gap exceeds 1%, as demonstrated below:

Hey @SwaptoX,

Thanks for your response. How are you identifying a token as verified or not?

Also, in the warning that you will show you users about the price gap, do you plan to also add what the possible outcome will be should the user accept the warning?

@axia

Thank you for the question. I’d like to clarify first that a “Verified” label does not represent any endorsement or guarantee of a token’s safety by SwaptoX.

On the DApp frontend, this label is presented as a visual indicator to help users understand a token’s relative risk profile based on on-chain verifiable data, liquidity conditions, and observable market behavior, rather than a security conclusion.

We plan to provide four types of risk indicators to help users quickly assess and make informed decisions:


:green_circle: Green Label (Relatively low-risk, commonly used tokens)

The green label is intended for tokens with higher transparency and broader usage, for example:

  • Verified contract source code with no obvious malicious permissions

  • Stable on-chain liquidity and trading activity

  • Long-term integration across multiple DEXs or applications

  • (As a reference signal) widely used across different ecosystems

This label only indicates relatively lower risk from a transparency and market-behavior perspective and does not constitute a safety guarantee.


:yellow_circle: Yellow Label (Medium risk – caution advised)

A yellow label is applied when the system detects one or more of the following:

  • Buy/sell price gap exceeding 1%

  • Abnormally high slippage compared to similar assets

  • Detected buy or sell taxes (static or dynamic)

These signals are derived from our existing quote engine and transaction simulation modules.
Yellow labels are always accompanied by a warning modal highlighting potential pricing or liquidity risks.


:red_circle: Red Label (High risk – strong warning)

A red warning is shown, along with repeated confirmation prompts, when high-risk signals are detected, such as:

  • Buy/sell price gap exceeding 20%

  • Unverified or opaque contract source code

  • Transaction restrictions (e.g. inability to sell, trading locks)

  • Clearly suspicious or high-risk contract functions

  • Highly centralized contract control with critical permissions not renounced

Price behavior and sellability are detected via on-chain simulation, while other contract-level signals are obtained through internal rules or third-party security data sources.


:white_circle: Grey Label (Insufficient information)

This indicates that the token does not meet the criteria for a green label, but no explicit high-risk signals have been detected.
It represents limited information rather than a safety assessment.


Price Gap Warnings and Possible Outcomes

Yellow and red labels are always accompanied by clear warning modals.
If a user chooses to proceed despite the warning, possible outcomes may include:

  • Receiving significantly fewer tokens than expected due to high slippage

  • Difficulty or inability to sell the token at a reasonable price

  • Transaction failures caused by insufficient liquidity, resulting in gas loss

  • Asset loss caused by hidden taxes or dynamic token mechanisms


In summary:

  • A green label ≠ a safety guarantee

  • A red label ≠ a token is necessarily fraudulent

These indicators are designed to increase risk visibility, support informed user decision-making, and improve overall safety and user experience.

1 Like

Helllo @SwaptoX, I saw that you resubmitted your Milestone 1 proposal on-chain. However the description you provided doesn’t match what you wrote in your off-chain proposal. What you provided off-chain is more robust in scope than what you wrote on-chain. Can you please explain this discrepancy?

Off-chain Milestone 1:

On-chain Milestone 1:

Verifiable Plan for Milestone 1 Completion

After development is completed, please visit: https://app.swaptox.com/?chain=rootstock

(The chain=rootstock parameter will automatically switch the network to Rootstock.) Alternatively, you can manually switch to the Rootstock network using the network selector in the top-right corner of the DApp.

Verification Steps:

1:Click “Connect Wallet” and successfully connect your wallet, then switch to the Rootstock network. Successful connection and network switching confirm that the DApp has integrated Rootstock network configuration and RPC interfaces.

2:Select tokens and request a quote, for example: RIF → RBTC RBTC → USD₮0

or any other token pair available in the token list. If the quote is returned successfully, this confirms that the quoting contracts and routing logic have been properly deployed.

3:Enter a small token amount and click “Swap Now.” When the swap confirmation modal appears, click confirm, which should trigger a wallet transaction request for on-chain execution. If the swap executes successfully, this confirms that the swap contracts have been deployed and are fully functional.

Completion of the above three verification steps will demonstrate that Milestone 1 has been successfully completed.

After completion, I will also provide the deployed contract addresses and a demonstration video of the full process. DiscourseLink:https://gov.rootstockcollective.xyz/t/2601-grant-swaptox-aggregator-milestone-1/700/30

1 Like

@axia

Hello, thank you for pointing this out.

There is no change in scope between the off-chain and on-chain Milestone 1 descriptions. The discrepancy is purely structural rather than substantive.

The off-chain proposal describes the full scope and objectives of Milestone 1, including:

  • Deployment of SwaptoX core contracts on Rootstock mainnet

  • Integration of Rootstock-native tokens and liquidity pools

  • Accurate routing, quoting, and execution

  • A publicly accessible swap UI

  • Support for at least 30+ tokens

The on-chain submission, however, was intentionally written as a verifiable execution plan, focusing on how milestone completion can be objectively validated on-chain by the community.

In other words:

  • The off-chain version defines what will be delivered.

  • The on-chain version defines how delivery can be verified.

The verification steps (wallet connection, quoting, and successful swap execution) are practical demonstrations that the contracts are deployed, routing logic is functioning, and liquidity integration is complete.

To be clear:
Milestone 1 will be executed strictly according to the full off-chain description. The on-chain content does not replace or reduce those commitments — it only explains how completion can be independently verified.

Hi @SwaptoX

I was hoping you could help me understand a few points regarding the project’s trajectory and logic to transition from Base to Rootstock now.

The initial description mentioned the project being production-deployed for over four months with extensive real-world testing.

However, the figures shared later seem low for a production environment on a high-traffic chain like Base.

Could you clarify why there is such a gap?

I’m also trying to understand the strategic reasoning behind expanding to a new chain like Rootstock before achieving user traction or a ‘proven product-market fit’ on the original chain.
Why move to Rootstock now instead of focusing on growing the user base where you are already deployed?
How will the strategy on Rootstock differ to ensure we don’t end up with similar low-activity levels here?
I appreciate the transparency and look forward to hearing your thoughts.

2 Likes

@DAOstar_gov

Hello — thank you for the careful review and for raising these points. I appreciate the chance to clarify.

1) On the apparent gap between “production deployment for over 4 months” and the on-chain metrics

Although we have deployed on Base, we have not conducted any significant marketing activities.
In fact, the real user transaction volume should be around 1000 transactions, as we upgraded the contracts several times during the process, and transactions on deprecated contracts have not been counted.

When we refer to extensive testing, we are talking about testing the feasibility of the technology and the accuracy and stability of the routing. There have been over 10,000 test transactions (automated trading by bots), which demonstrates the feasibility and stability of the technology. Base has been a technical testing ground, not a growth experiment.

For an aggregation infrastructure product, verifying the correctness of the routing logic and execution is the primary task before scaling the user base.


2) Why expand to Rootstock before achieving large user growth on Base?

Our priority right now is not to focus on growing the user base on the current deployment platform.
We believe the product is not yet mature enough and lacks sufficient competitive advantages. Currently, we are still in the development phase. As mentioned earlier, we plan to form a small team in 6 months.

Why 6 months?
We expect it will take around 3 months to complete the milestone mentioned above, after which I will need an additional 2 months to develop advanced routing and features, such as the “limit price execution” and “precise output” functions. This timeline of about 5–6 months will ensure that our product is fully refined.

At that point, the first-stage team we will hire will be focused on marketing, not technical development. This is when we will focus on user acquisition.

By then, not only will we be promoting the DApp, but we will also be promoting the Mini SDK (Mini UI version) for quick integration in 10 minutes, as well as offering API-based lightweight quoting bots and trading bots for integration.


3) How will the strategy on Rootstock differ?

On Base:

  • The focus was on technical validation, with no active growth incentives, and the competition is fierce. We have not yet conducted any meaningful marketing or promotional activities.

On Rootstock:

  • There is grant support and community backing, which will help SwaptoX establish itself quickly in the Rootstock ecosystem.

  • The competition on Rootstock is lower, and there are clear differentiators from existing aggregators, which gives us a natural competitive advantage.

  • The grants will accelerate our ability to complete the milestones, and after 5–6 months, we will actively begin to form a marketing team.

Our goal on Rootstock is to gain the first batch of users, establish a strong presence, and then expand into a multi-chain strategy once we have firmly established ourselves on Rootstock.

We believe that expanding our influence on Rootstock will be more efficient and cost-effective compared to Base. Therefore, after product development is complete, we will prioritize marketing and incentivization activities on Rootstock to build and stabilize our core user base.

1 Like

Hey @SwaptoX, I went ahead and voted FOR funding Milestone 1. You can find more detailed rationale here. Just want to note that the Collective will be evaluating your Milestone 1 outcomes against what you wrote on the governance forum, not necessarily what’s on-chain. The two should have matched, but I don’t think it’s a reason to delay funding this proposal right now.

@Axia Thank you for your support! I fully agree with the community verifying Milestone 1 according to the established rules and will actively cooperate by providing the necessary verification information. The on-chain submission is simply a simplified version of the verification process, aimed at ensuring transparency and clarity for easier review.

@SwaptoX Appreciate the responsiveness and persistence shown so far.

We decided to support this project.

We don’t think only mature projects with proven traction should get grants. Those can raise venture capital at million dollar valuations.
Grants are meant for pre-seed projects, with little to no proven traction, which would have difficulty raising venture capital.

Moreover, we think Rootstock could use an improvement in the DEX space, which could come in the form of an aggregator.

Deffinitely agree with @Axia, the important content is what’s discussed here in the forum. The on-chain text if often overlooked.
I like your idea of presenting the deliverables in a more objective structure. This can make sense when you finish M1 and it’s time to present it.