[2601 Grant] SwaptoX Aggregator – Milestone 1

Grants & Incentives
21

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

22

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.

23

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.

25

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
26

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.

27

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.

28

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

360截图20260210012811162
360截图20260210012811162792×588 93.1 KB

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:

2026-02-10
2026-02-10498×168 18.6 KB

29

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?

30

@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
31

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
32

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

33

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
34

@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
35

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.

36

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

37

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

38

Deeply appreciate the support and affirmation from @ChronoTrigger ; this gives me great encouragement. Special thanks as well to @Axia for the leading support, and to everyone else who has supported me. Thank you very much.

Regarding the concerns from @daostar_gov , I would like to state the following:

  1. On Project Maturity: There is no conflict between SwaptoX being live on Base for 5 months and the statement that SwaptoX is currently not yet “perfect.” The swap functionality of SwaptoX is fully functional and can be used by anyone on Base. However, since even the most basic documentation has not yet been developed, I consider it still imperfect. Both are objective facts.

  2. On the KYC Issue: I apologize for the earlier KYC issue. I believe there are no problems with my KYC and it will be approved soon. At that time, there were no new comments or questions. I believe that the KYC process and the on-chain proposal can proceed simultaneously.

  3. On Being a Solo Developer: Regarding independent development, most major aggregators do not provide open-source solutions because their routing is a core competitive advantage. It was not easy for me to self-develop the aggregator based on my previous arbitrage experience. As the founder and developer, I own 100% of SwaptoX. SwaptoX has become my core asset; unless a major personal accident occurs, no one would stop maintaining or give up their own asset.

Furthermore, the fact that Rootstock provides individual KYC certification proves that the Rootstock ecosystem does not exclude individual developers.

2 Likes
39

Although the proposal was not passed in this round, the final tally is 5:5, representing 73% of the voting power. First of all, I would like to sincerely thank the 5 supporters; your support has given me sufficient confidence and motivation to continue advancing this proposal. At the same time, I also appreciate the feedback provided by the dissenters. I have responded to 4 of them individually (one dissenter has not yet provided a rationale), and I look forward to everyone’s feedback. I plan to continue the discussion for one week and re-submit the proposal on-chain after that. I look forward to receiving more diverse opinions during the discussion; questions are welcome.

Below, I will summarize and clarify several representative issues:

1. Regarding the claim that 5 months on Base without gaining traction proves SwaptoX lacks “pulling power”: The Base ecosystem is different from Rootstock; Base has too many choices and its ecosystem is even “oversupplied,” while Rootstock has fewer choices and is somewhat “undersupplied.” Furthermore, we did not execute any promotion plans on Base. The lackluster performance of SwaptoX on Base cannot be equated to its potential performance on Rootstock. Running for 5 months should be seen as a strength, proving the developer’s ability for continuous maintenance and cost expenditure. We view this project as infrastructure—long-term construction and stable development. We do not expect immediate attention. The fact that the developer has spent significant time and effort, self-funding operations for a year with the current priority still being development and improvement, is sufficient proof of this.

2. Excessive requirements for solo developers or unclear risk judgment: Everyone knows the risks of solo developers, yet Rootstock still provides KYC processes and solutions. If a solo developer, who has self-developed (with no existing open-source solutions to reference or copy) for over half a year and self-funded operations for 5 months, is still labeled as “High Risk,” are the requirements for solo developers too high? If you are concerned about unknown risks such as single-point-of-failure or personal accidents, I completely understand, but I suggest defining the minimum standards for solo developers; otherwise, such unknown risks without evidence will be difficult to define.

(The above two points are responses to the questioning of SwaptoX and myself)

3. This project is a huge challenge for a solo developer: It is precisely because I face huge challenges that I am applying for a grant. Fortunately, the core part has been completed, and I have solved the technical problems alone. We do not need to hire a development team in the short term, which greatly reduces costs. This grant will help us assemble a marketing team, which will be more cost-effective and efficient.

4. Regarding the grant, I must quote the excellent response from @ChronoTrigger**:**

5. Unable to provide verifiable Rootstock deployment contracts: This is a procedural issue; Milestone 1 is the migration and deployment. An aggregator is not a static contract; it requires cooperation with liquidity contracts. This is a complex task involving the deployment of quotation contracts, trading contracts, liquidity collection, liquidity info polling bots, and the integration of frontend and backend. Only after completing Milestone 1 can I provide verifiable Rootstock deployment contracts.

Finally, I am providing a more detailed explanation of Milestone 1 after further investigation:

  1. Deploy SwaptoX core contracts on Rootstock mainnet.

  2. Integrate Rootstock native tokens and liquidity pools, including liquidity from WoodSwap, Sushi, and UniSwap. (Since UniSwap does not list a Rootstock network entry, I discovered its liquidity via on-chain data).

  3. Ensure accurate routing, quotation, and execution.

  4. Provide a publicly accessible Swap UI connected to Rootstock.

  5. At least 30+ supported tokens in the initial deployment. (Liquidity is increased but not the number of tokens. Specific tokens can be viewed via the block explorer; 28 tokens have logos and price info: ).

  6. Deploy liquidity sorting and quotation bots.

Some of the 30+ tokens may lack liquidity, but they already include all tokens on the Rootstock network for which liquidity has been created (even if liquidity is low or zero). The liquidity quotation bot primarily obtains price data for tokens and displays prices on the frontend, including 24-hour price trends. The liquidity sorting bot is used for the swap algorithm; we will obtain liquidity data in real-time for sorting. During quotation, if the routing passes through too much liquidity, we will filter based on liquidity ranking to ensure performance and stability.

40

[Proposal V2] SwaptoX Aggregator: Detailed Information, Lower Risk, and Advanced Features

Following the first round of voting, I realized that the previous proposal was not sufficiently clear regarding technical details and security measures. To address these concerns and reduce the perceived risk for the community, I have updated the proposal to Version 2 (V2). This version includes more granular milestones, lower initial funding requirements, and a commitment to delivering advanced functionalities.

Redefining Milestones to Mitigate Risk, Increase Detail, and Solidify Commitments

Milestone 1 – SwaptoX Deployment on Rootstock (1 Month)

  • Objective: Deploy SwaptoX as a native swap aggregation infrastructure on the Rootstock network.

    1. Deploy SwaptoX core contracts on Rootstock mainnet.

    2. Integrate Rootstock native tokens and liquidity pools, including liquidity from WoodSwap, Sushi, and UniSwap.

    3. Ensure accurate routing, quotation, and execution.

    4. Provide a publicly accessible Swap UI connected to Rootstock.

    5. Support at least 30+ tokens in the initial deployment.

    6. Deploy liquidity sorting and quotation bots.

  • Requested Support: $2,000 (Reduced amount to minimize initial collaboration risk). (This amount is intended only to cover basic server costs and mainnet deployment overhead, demonstrating our sincerity in establishing long-term collaborative trust with Rootstock.)

Milestone 2 – Swap Mini SDK Development for Easy Integration (UI-focused SDK) (1 Month)

  • Objective: Lower the integration barrier for Rootstock ecosystem projects by providing a lightweight Swap SDK.

  • Technical Implementation:

    1. Provide a complete, composable token swap UI; dApp developers only need to write minimal JS logic to implement Swap functionality.

    2. Development Stack: Utilizing Web Components + Lit architecture for both native compatibility and high performance.

    3. DOM Isolation: Utilizing Shadow DOM to prevent style or logic pollution within the integrator’s dApp.

    4. Compatible with any frontend framework, including React, Vue, Angular, or native JS+HTML.

    5. Lightweight usage: Providing boilerplate code, allowing integration within 10 to 60 minutes depending on developer proficiency.

  • Additional Details:

    1. Multi-language configuration: Built-in support for Chinese, English, Japanese, and Korean, with options for custom languages.

    2. Multi-theme support: Built-in Light/Dark modes with customizable themes to match the host dApp’s branding.

    3. Responsive design: Fully compatible with mobile and desktop screens.

    4. Customizable Token Lists: Integrators can restrict the token selection to specific “safe” tokens to ensure user security.

    5. Output-only restrictions: Useful for integrators who only wish to facilitate the acquisition of a specific token rather than offering a general aggregator.

    6. Integrator Revenue Sharing: Integrators can embed their wallet addresses to receive a 30% share of protocol fees generated (Note: Protocol fees are currently 0; hence rewards are not yet active).

  • Use Cases: Wallet extensions or dApps requiring token operations (e.g., when a user lacks a specific token required for a dApp function).

  • Requested Support: $5,000

Milestone 3 – Public API & Developer Documentation (1 Month)

  • Objective: Enable advanced integrations such as trading bots, analytics platforms, and BTCFi derivatives.

  • Documentation is a fundamental requirement for any DEX; this will be provided in both Chinese and English across three sections:

    1. Detailed operation and usage guide for the SwaptoX UI.

    2. Integration examples and detailed documentation for the Mini SDK.

    3. API specifications: Request/response formats and data schemas.

  • Includes Swap contract ABI documentation to facilitate direct smart contract interactions with the SwaptoX Router.

  • Open access to APIs for price discovery, token lists, and price feeds (Limit order APIs will be released following Milestone 4).

  • Requested Support: $5,000

NEW Milestone 4 – Commitment to Advanced Features: “Limit Orders” and “Exact Output” (2 Months) In the previous version, these were only informal promises. In V2, we have reallocated funds from Milestone 1 to officially include these advanced features in the roadmap to ensure successful delivery.

  • Limit Orders: Allows users to set specific triggers (e.g., “Buy ETH if price < 2500” or “Sell if price > 2600”).

    • Use Cases: Direct order placement/cancellation within dApps, strategy bots, and grid trading bots.

    • Technical Challenge: Requires a third-party “Keeper” network (platform bots or incentivized users) to execute trades. Since Keepers must pay Gas, their profit must cover Gas costs for the system to remain viable.

    • Solution: We clearly notify users that execution is not instantaneous upon hitting the trigger price. For example, if a user sets a price at 2600 and the Gas cost is 0.6U, a Keeper may only execute once the price hits 2600.8 to ensure profitability. Open competition among Keepers will optimize this spread.

  • Exact Output: Useful for users needing a precise amount of an asset (e.g., exactly 0.5 BTC or exactly 1000 RIF for staking) or for future “Online Payment” integrations.

    • Technical Challenge: Unlike “Exact Input,” this requires a reverse routing algorithm, which is significantly more complex for an aggregator. We will implement this by reverse-invoking the exact output logic across the routing path.

  • Requested Support: $5,000

Total Duration: 5 Months | Total Requested Support: $17,000 (Compared to V1’s $15,000 for basic infrastructure, V2’s $17,000 includes the delivery of two highly complex advanced features, averaging $3,400 per month.)

Differentiation of “Limit Orders” and “Exact Output”

While OpenOcean supports limit orders on other networks, the feature is not listed for Rootstock. “Exact Output” is currently unsupported by many aggregators like 1inch, KyberSwap, and OpenOcean (manifested as the second output box being disabled).

Why prioritize these advanced features now?

Integrating these features prior to a unified security audit is more cost-effective and avoids the need for re-auditing later. Furthermore, launching a highly polished and feature-complete product provides a significant competitive advantage and attracts top talent to the project.

Clarification regarding @Curia suggestion on Growth Milestones

We appreciate Rootstock’s willingness to fund growth. However, we currently lack baseline data for acquisition costs (CPA), retention, and conversion rates on Rootstock. We prefer to define a professional growth milestone once data is available after deployment. Our current priority remains technical development, followed by security audits and scaled growth.

Regarding Security Audits

We prioritize safety and are exploring alternative funding for audits. I have engaged with the co-founder of FailSafe regarding their grant program (Details: https://getfailsafe.com/apply). We also noted that Optimism provides audit grants for supported chains including Base (Details: https://atlas.optimism.io/missions/audit-grants). We intend to finalize an audit plan once we confirm the availability and scale of these external subsidies.

Other Security Details:

  • Non-custodial: The protocol does not hold user funds.

  • Non-upgradeable: Core contracts will include a renounceOwnership() function to be triggered once the system is stable.

Impact of Deployment on Rootstock

Milestone 1 covers 30+ tokens, effectively encompassing all meaningful assets on Rootstock (including low-liquidity pairs). According to block explorers, there are roughly 28 tokens with logos and price data on Rootstock; SwaptoX will cover them all (Details: https://rootstock.blockscout.com/tokens). If it can be swapped on another Rootstock DEX, it will be swappable on SwaptoX.

Technical Feasibility and Challenges

The primary challenge is growth; the technical challenge is manageable. While the milestones are complex, the “0 to 1” development of the core architecture is already complete. We are now in the “1 to 1.5” refinement phase. With the grant support and milestone commitments, we are fully confident in our delivery.

Growth Potential

While we cannot provide a blind growth forecast, we believe SwaptoX holds a competitive advantage on Rootstock due to its total asset coverage and high product maturity. We will self-fund initial growth experiments to obtain reliable data before seeking dedicated growth capital from Rootstock.

Priority Commitment to Rootstock

We commit to prioritizing Rootstock for both technical and growth support. SwaptoX needs to establish trust and market share within a specific ecosystem before considering multi-chain expansion. Compared to the oversaturated Base market where we lack support, Rootstock represents a significant “Blue Ocean” opportunity. We intend to focus our R&D where we have the highest potential to become a native leader. We aim to gain our first core user base and market share here on Rootstock before considering other plans.

41

@SwaptoX , we appreciate your continued engagement, the detailed V2 update, and the effort to reduce perceived risk. The revised Milestone 1 is clearly structured and the reduced initial ask is reasonable. While we are still not confident in the project’s ultimate success due to the limited track record of achieving sustained user adoption, the current Milestone 1 design is generous and thoughtfully scoped, which leans us toward being supportive in principle.

That said, our main concern remains product-market fit, not feature completeness.

We would strongly recommend stripping out the advanced features for now and reallocating focus toward measurable growth initiatives, while also reducing the total grant amount. The core question is whether the product can achieve real usage on Rootstock, not whether it can ship more functionality. Even if Milestone 1 makes technical sense, we would vote against it if the broader roadmap prioritizes feature expansion over user traction.

We understand your point about lacking baseline data for CPA or retention. However, that does not prevent you from estimating assumptions and committing to explicit targets. Based on the usage achieved by the previous milestones, a growth-focused milestone can define clear KPIs such as:

  • Minimum unique active wallets
  • Swap volume targets
  • Integrations completed
  • Retention benchmarks
  • Cost per acquired user assumptions and experiments

Without concrete adoption targets and deliverables tied to usage, we cannot properly evaluate ecosystem impact.

Our recommendation:

  • Combine Milestone 2 and Milestone 3.
  • Redefine the new Milestone 3 as a growth initiative with explicit adoption KPIs.
  • Remove Milestone 4 entirely at this stage.
  • Security audit planning can be incorporated into Milestone 2 or the revised Milestone 3.

We are still not convinced that maintaining deployment on Base constitutes meaningful proof of success. However, we agree with the broader point raised by supporting delegates that grants are meant for pre-seed and solo founder projects. We are open to supporting such initiatives, provided the roadmap is centered on validating demand rather than expanding scope.

If you can incorporate this feedback and refocus the proposal around measurable product-market validation, we would be more comfortable reconsidering our position.

2 Likes