[2601 Grant] SwaptoX Aggregator – Milestone 1

Grants & Incentives
42

@Tane

Thank you for your review and detailed recommendations.

I would like to clarify that it is not a lack of focus on growth, but rather a difference in our prioritization. My previous focus on technical completeness was driven by the need to manage future audit costs and my belief that a fully featured product is essential for establishing broad user trust. However, I agree with the community’s feedback to deprioritize advanced features for now and focus on validating Product-Market Fit (PMF). We will revisit the advanced functionalities in later stages once the core traction is established.

Redefined Milestones: V2.1

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: $3,000

Technical Complexity Note: Aggregators are not static contracts; they require extensive on-chain engineering and integration with various liquidity protocols:

  • WoodSwap: A rare liquidity protocol that requires manual contract analysis due to lack of documentation.

  • UniSwap: Mainstream V2/V3 protocol, but requires manual on-chain exploration for Rootstock deployment parameters.

  • Sushi: Mainstream V2/V3 protocol integration.

Milestone 2 – Swap Mini SDK, Public API, and Documentation (45 Days)

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

Technical Implementation:

  1. Composable UI: A complete swap UI where dApp developers only need minimal JS logic to enable Swap functionality.

  2. Modern Architecture: Built with Web Components + Lit for native compatibility and high performance.

  3. DOM Isolation: Shadow DOM ensures no style or logic pollution to the host dApp.

  4. Framework Agnostic: Compatible with React, Vue, Angular, or native JS/HTML.

  5. Efficiency: Optimized for a “10 to 60-minute” integration time depending on developer proficiency.

Advanced Features:

  1. Multi-language: Built-in English, Chinese, Japanese, and Korean support (customizable).

  2. Theming: Built-in Light/Dark modes with full theme customization.

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

  4. Token Whitelisting: Integrators can restrict the token list to specific “safe” assets.

  5. Output Restrictions: Ability to lock the output token for specific use cases (e.g., payment gateways).

  6. Layout Flexibility: Can be embedded directly into a page or triggered via a modal.

  7. Incentive Alignment: Integrators can embed their wallet addresses to receive 30% of protocol fee rewards (Revenue sharing is ready and will activate once protocol fees are enabled).

Use Case & Strategy: We position the Mini SDK as a strategic integration layer for ecosystem expansion. By providing a high-quality, low-cost integration tool, we create a growth lever where every integrated dApp becomes a traffic entry point for SwaptoX, building brand influence and transaction volume.

API & Documentation:

  • Public API: Open access with no initial rate limits to encourage developer adoption.

  • Documentation: High-efficiency developer docs focusing on rapid SDK and API integration.

Requested Support: $7,000

Milestone 3 – Growth & KPI Validation (2 Months)

Objective Validate product-market demand and establish measurable ecosystem traction within Rootstock.

Target KPIs (60 Days):

  • 400–600 unique trading wallets.

  • 800–1,200 on-chain swap transactions.

  • $100k–$150k cumulative trading volume.

  • 2–3 external dApps integrating the Mini SDK.

Rationale: Rootstock currently processes approximately 6,000–10,000 transactions per day. Assuming ~20% are DEX-related, estimated swap volume would reach ~96,000 transactions over 60 days. Targeting ~1% of ecosystem swap activity represents a realistic yet meaningful benchmark for an initial launch.

The $5,000 budget is structured as a blended growth model, combining direct user incentives, ecosystem integration support, and marketing efforts. Based on this allocation, the effective acquisition cost remains within a mid-range Web3 benchmark, with direct wallet activation estimated in the ~$6–10 range and additional growth leverage expected from SDK integrations.

Verification Method:

  • Public dashboard (Dune Analytics / custom indexer).

  • Contract address transparency.

  • SDK integration proof (live deployment links).

Budget Allocation Plan:

  • $1,500: User incentives (trading rewards/campaigns).

  • $1,500: Ecosystem integration grants for partners.

  • $2,000: Marketing and community outreach.

Requested Support: $5,000

Summary of Funding

  • Total Requested: $15,000

  • $10,000 Technical Grant (Ensuring long-term stability and infrastructure).

  • $5,000 Growth Grant (Dedicated to market validation and user acquisition).

Detailed verifiable plans for each milestone will be provided during the on-chain voting phase.

1 Like
DAOstar Delegate Thread (rev)
43

I previously voted in support, so maybe the comments of those who voted against are more important at this moment.

Nevertheless, I also strongly feel the advanced features (limit order and exact output) shouldn’t be a concern, and are probably better kept for after a product validation. I’d leave them out of the first milestones. Better to focus on getting the MVP right.

1 Like
44

@ChronoTrigger

Thank you for your continued support and thoughtful input.

I fully agree that product validation (PMF) should take precedence over advanced features. In V2.1, the focus has been realigned toward core deployment, SDK accessibility, and measurable growth KPIs. Advanced order types will only be reconsidered after confirming real market demand and usage.

The immediate priority is execution and validation.

2 Likes
45

Thanks for the detailed revisions and for genuinely engaging with the feedback. I think V2.1 is clearly more focused than the original version, especially shifting priority toward PMF and measurable traction instead of expanding features.

Just to clarify my position: my previous vote wasn’t about blocking early-stage builders, nor about requiring deployment before funding. It was mainly about clarity of impact and execution risk at that stage.

Now that the scope is tighter and the initial ask is lower, the key question for me becomes simpler:

What makes Rootstock structurally different from Base in terms of distribution?

On Base, the product was live for several months and showed some usage (~150 transactions), but growth was still limited. Rootstock is smaller in absolute size, even if it may be less saturated. So for the PMF targets to be realistic here, I think it would help to understand what concrete growth levers exist beyond general incentives and marketing.

For example:

  • Are there any early conversations with dApps that could integrate the Mini SDK?

  • Any wallet-level interest?

  • Any ecosystem partners willing to experiment alongside you?

I’m not expecting signed agreements, just trying to understand what could realistically move the needle here. If we can anchor the growth assumptions in something tangible, I think the proposal becomes much stronger

2 Likes
46

@Kaf_Anode

Thank you for raising this question. I believe it is a key point and deserves a clear explanation.

If we assume that SwaptoX completes its audit and establishes baseline trust during the process (the audit will be advanced alongside Milestone 3, prioritizing external subsidy options as mentioned in V2, and if necessary discussed further with the Rootstock community), then the difference between Rootstock and Base is not merely ecosystem size, but structural distribution dynamics.

During the Base phase, our product functioned essentially as a standalone aggregator frontend. We had no SDK-based distribution capability and no embedded ecosystem integration path. In a highly mature and competitive environment where users already had multiple established swap entry points, there was no structural distribution leverage. Under those conditions, simply being live was not sufficient to generate meaningful growth.

In Rootstock, however, our positioning evolves.

:one: Structural Composability

For example, protocols such as Oku, which optimize and rank aggregator outputs, are structurally compatible by design. Oku’s logic is to compare and sort outputs from multiple aggregators, while SwaptoX focuses on lower-layer liquidity optimization and routing computation. These layers are naturally composable — just as we integrate multiple liquidity sources to optimize execution, higher-level sorting protocols can include SwaptoX as one of their routing sources for comparison.

The key point here is not a specific partnership, but structural compatibility and composability.

:two: The “Token Entry” Problem Within DApps

A common scenario across many DApps is the following:

  • A DApp requires a specific token (e.g., RIF or another native token)

  • The user’s wallet only holds rBTC or stablecoins

  • The user must leave the DApp to swap tokens via a third-party platform

  • This creates friction, fragmented UX, and trust uncertainty

This scenario is common across DeFi, GameFi, and wallet extensions.

The Mini SDK is designed to solve precisely this issue.
Its objective is not to compete for frontend traffic, but to become a token exchange infrastructure layer within the ecosystem.

:three: Structural Advantages of the Mini SDK

The Mini SDK provides:

  1. Broad token coverage across the network

  2. A high-performance, composable, and embeddable professional-grade architecture

  3. A revenue-sharing mechanism for integrators

  4. Low integration overhead (approximately 30 minutes)

In addition, we provide services that large aggregators typically do not prioritize:

  • Rapid listing of specific assets (such as a DApp’s native token)

  • Fast response time and reasonable customization support when needed

This level of flexibility is particularly valuable in a developing ecosystem.

:four: Early Integration Support Framework

To lower experimentation barriers, we plan to establish an Early Integration Support Program:

  • Free SDK usage for ecosystem partners

  • Rapid technical support

  • Stage-based integration incentives aligned with real usage

This is not simply a short-term incentive mechanism, but a way to validate the embedded distribution model.

:five: Structural Differences in Rootstock

Rootstock currently does not have a standardized, high-quality, embeddable swap SDK infrastructure solution.

Across multiple ecosystems, wallets and DApps typically rely on professional aggregator APIs rather than building their own routing engines. This reinforces that the aggregation layer functions as infrastructure, not merely as a competing frontend.

On Base, we were positioned as a frontend participant.
On Rootstock, we aim to position SwaptoX as infrastructure.

That is the structural difference.

Therefore, our growth assumption is not purely incentive-driven. It is based on:

  • Lower competitive density

  • An open infrastructure layer opportunity

  • An SDK-based embedded distribution model

  • Revenue alignment with integrators

If this structural thesis holds, then targeting ~1% of ecosystem swap activity becomes a realistic and measurable objective.

To clarify directly: we have not yet entered a formal integration phase, as the Mini SDK has not been released. However, the distribution pathways are clearly identifiable — including wallets, token-entry DApps, and aggregator-ranking protocols. Our growth hypothesis is built around embedded distribution rather than relying on standalone frontend traffic.

2 Likes
47

The V2 proposal has been updated to V2.1 after one week of community discussion. No new feedback has been received in the past two days.

To move the project forward, I have submitted the on-chain proposal for voting.

The voting period will last one week. If there are still questions, please feel free to continue the discussion in the forum. Community members are welcome to vote after fully reviewing and understanding the proposal.

Thank you all for your time and support.

48

After reviewing version 2.1, along with the community feedback and @SwaptoX’s responses, I voted FOR this proposal. My full rationale is outlined in Axia’s Delegate Thread.

1 Like
49

Hi @SwaptoX

Thank you for taking into consideration feedback from delegates and adjusting the proposal.

Are you currently pursuing or have you received grants from other ecosystems for SwaptoX? If so, how do you plan to manage concurrent milestone commitments, and is any of the requested budget here covering work that is also being funded elsewhere?

We appreciate your openness and cooperation as part of our delegate due diligence process.

50

@DAOstar_gov

Thank you for the question.

I applied to several ecosystems about two months ago, but since then, I have not pursued any new grants. To date, the only positive response I’ve received has been from Rootstock.

There are currently no concurrent milestone commitments, and no overlapping budget coverage. The requested budget in this proposal is dedicated specifically to the Rootstock deployment and related milestone deliverables outlined in V2.1.

If any future grants were to be secured, I would ensure that the scope and funding allocations are clearly separated to avoid any duplication of work or budget overlap.

I appreciate the due diligence process and am happy to provide further clarification if needed.

2 Likes
51

Thanks @SwaptoX for the clear and quick response.

1 Like
52

this looks like a good addition to the ecosystem and I like the fact there is a relatively quick go to market plan for milestone 1 with the SDK to follow. Nice one.

3 Likes
53

GM @SwaptoX

Is your deployment purely global by default, or are you prioritizing specific regions for traction? If prioritizing, how does that regional strategy create incremental value for the Rootstock ecosystem?

1 Like
54

@tamlerner

Thank you for the question.

At this stage, the deployment is globally accessible by default, and our focus is on product integration rather than regional marketing. The immediate goal is to build infrastructure and SDK solutions that can be seamlessly adopted by dApps, wallets, and other integrations, driving traction across various ecosystems.

While we are not prioritizing any specific region at this time, SwaptoX DApp supports multiple languages, including Chinese, Japanese, and Korean. This multilingual support positions us well for engagement in Asian markets, where decentralized finance (DeFi) is gaining increasing attention.

If regional strategies become more relevant in the future, Asia may become a focus given the growing interest in blockchain and DeFi in countries like Japan, South Korea, and China. The multilingual support (Chinese, Japanese, Korean) offers us a potential advantage in parts of Asia where Rootstock’s presence is still developing. Any traction generated in these regions would contribute to exposure beyond Rootstock’s existing user base.

1 Like
55

Hi @SwaptoX just wanted to let you know I’ve voted in favor of the proposal.

I still think execution and measurable impact will be key going forward, but I’m supportive of allowing Milestone 1 to move ahead and seeing how it performs on Rootstock.

I also think the discussion around potentially focusing on a specific region where you may have stronger networks or market understanding is a positive angle. Looking forward to seeing the deployment live and the next steps.

2 Likes
56

@Kaf_Anode

Thank you so much for your support, and to all the delegates who participated in the vote! I’m very pleased to see that Milestone 1 has successfully passed and reached the required number of votes.

I will now begin working on Milestone 1 and aim to deliver on the commitments by April (at the latest, I will complete it by April 5th). I will ensure the work progresses according to plan, keeping transparency and providing regular updates.

Regarding your suggestion about focusing on specific regions, I fully agree and will continue to monitor the market dynamics, especially in the Asian region, to further optimize our strategy and enhance our presence in these markets.

Once again, thank you for the support and trust. I look forward to the results in the coming months, and I will continue to follow up on the project progress as we move forward with the next milestones.

4 Likes
57

Hi @SwaptoX, I voted in support for the V2.1 Proposal. Thanks for the updates on M1!

You can check my latest rationale here

2 Likes
58

Milestone 1 Completion Report

Deliverables Status Overview

  1. Deploy SwaptoX core contracts on Rootstock mainnet. :white_check_mark: All associated contracts have been deployed; quotation and swap functions are fully operational.

  2. Integrate Rootstock native tokens and liquidity pools, including liquidity from WoodSwap, Sushi, and UniSwap. :white_check_mark: Integrated liquidity from WoodSwap, Sushi, and UniSwap. Additional integrations completed for Sovryn and ElkV2.

  3. Ensure accurate routing, quotation, and execution. :white_check_mark: Successfully verified 13 on-chain transactions with zero calculation errors or execution failures. (Simulated transactions have been tested hundreds of times across various protocol combinations).

  4. Provide a publicly accessible Swap UI connected to Rootstock. :white_check_mark: Accessible via the DApp UI link below.

  5. Support at least 30+ tokens in the initial deployment. :white_check_mark: Currently supporting 44 tokens.

  6. Deploy liquidity sorting and quotation bots. :white_check_mark: Real-time price trends are viewable by clicking the (!) icon next to the tokens.

Project Links

Integrated Protocols

  • Sovryn

  • WoodSwap (based on iZiSwap, an extended version of Uniswap V3)

  • SushiV2

  • SushiV3

  • Uniswap V2

  • Uniswap V3

  • ElkV2
    (Elk and Sushi follow Uniswap V2/V3 models)

On-chain Liquidity Discovery

Due to some DEXs not providing publicly indexed liquidity, we implemented on-chain discovery to collect liquidity data.

We analyze token holder contracts of popular tokens to determine whether they represent swappable liquidity. Once identified, we trace the originating factory contracts and extract all liquidity pools created by those factories.

This approach enables us to proactively discover and integrate tradable on-chain liquidity even without official indexes or listings.

Using this method, we additionally discovered liquidity from Sovryn and ElkV2. ElkV2 has relatively limited liquidity, while Sovryn provides more substantial liquidity.

Sovryn is a decentralized exchange built on Bitcoin. It allows users to trade, borrow, lend, and earn yield. Sovryn is a DAO and one of the most feature-rich DeFi platforms on Bitcoin.
Sovryn DApp: https://sovryn.app

(Through factory tracking and holder contract analysis, we have covered the major tradable liquidity sources currently available and have not identified additional significant liquidity sources.)

About Tokens

The 44 supported tokens were not arbitrarily selected. We do not curate tokens directly; instead, we aggregate liquidity, and the associated tokens are derived from those liquidity pools.

Although some tokens cannot be effectively swapped due to low liquidity, each token is associated with at least one liquidity source.

Gas Optimization

All routing interacts directly with liquidity pools rather than external routers.

An exception is Sovryn, where liquidity can only be accessed via the SovrynSwapNetwork contract, so routing must go through its router.

If multiple consecutive Sovryn pools are involved, we combine operations to reduce gas consumption.

Additional optimizations include direct token transfers between pools where applicable. For example, when routing into a V2 pool, tokens from the previous step are sent directly to the next pool, reducing redundant transfers while remaining within Router-controlled execution flow.

Open Source

Due to system complexity, we provide partial open source. Below is the system architecture:

  1. Data processing bots (liquidity ranking, token pricing, analytics)

  2. Redis cache layer (for high-frequency data processing, especially on Base)

  3. Persistent database

  4. Backend (API services)

  5. Frontend (DApp UI, Mini-SDK, admin UI)

  6. Smart contracts (4 contracts):

    • Utils: batch token info and liquidity queries

    • Quoter: pre-swap quotation (data from Redis and database; users should query via API)

    • Entered: execution contract for swaps, called by Router

    • Router: main user entry for swap execution

We provide partial open source to ensure user safety:

:white_check_mark: DApp UI and Mini-SDK (open source)
:white_check_mark: Router contract (open source + audited)

Translation error: the original meaning was (open source required + audit required).

Rationale:

  1. Mini-SDK must be open for integrators

  2. DApp UI transparency ensures safe user interaction

  3. Router auditability guarantees swap safety

The system assumes Router-level trust minimization:

  • Liquidity sources are not assumed to be trusted

  • If a pool fails to return expected output, the transaction reverts

  • Similarly, Entered is treated as an execution layer, not a trusted component

Although Entered is not open-sourced, it is designed as a stateless execution contract. Any tokens held by the contract are treated as part of the current execution context.
(Users SHOULD NOT send tokens directly to the contract.)

The contract does not implement fund custody or management logic beyond execution.

Security documentation (including admin risk model):
https://www.swaptox.com/view/security-overview.html
Audit-oriented version:
https://www.swaptox.com/view/security-model.html

Summary:
Router enforces post-swap balance checks to ensure that the received output meets or exceeds the quoted minimum. Any deviation results in a full transaction revert, ensuring atomic execution safety.

Planned Enhancements (Not part of Milestone 1 scope)

  1. “Best Route & Fee” display not yet implemented

    • The swap UI uses Mini-SDK (currently ~20% complete)

    • Route transparency will be added (Planned for Milestone 2)

  2. Transaction history not displayed

    • Will be implemented (Planned for Milestone 2)

  3. Token risk warnings

    • Risk tokens are currently ranked lower

    • Warning system not yet implemented (Planned for Milestone 2)

  4. Permit-based token approval (ERC20; not all tokens support permit)

Current flow:
approve → swap (two transactions)

Planned flow:
permit → swap (single transaction)

Permit allows off-chain signature instead of on-chain approval.

Due to slower block times on Rootstock, reducing one transaction significantly improves UX.
Smart contracts already support permit; UI integration is pending (Planned for Milestone 2).
OpenOcean currently does not support permit.

Advanced Routing (Split Routing Not Yet Supported)

On Base, this limitation is not significant due to deep liquidity and lower ETH price.

For example, using 1 ETH, our output is nearly identical to other aggregators.

However, on Rootstock, due to lower liquidity and higher BTC price, the difference becomes noticeable.

When quoting 1 BTC, OpenOcean achieves $50–$100 higher output.

This is because OpenOcean uses split routing:

  • 40% → route1

  • 30% → route2

  • 30% → route3

Since price impact is non-linear, splitting trades reduces slippage.

In our case, routing itself is not the bottleneck—we already support multi-hop, cross-protocol routing. The main challenge lies in optimal split ratio algorithms.

We plan to research split routing after Milestone 2–3.

For now:

  • Trades below ~$2000: performance is comparable or sometimes better

  • Small trades do not benefit significantly from splitting

  • Splitting may increase gas cost

  • We support broader liquidity sources (e.g., WoodSwap not listed in OpenOcean)

For larger trades, aggregators with split-routing strategies may achieve better execution.

Token Pricing System (Why Prices May Appear Lower)

Each exchange has its own pricing mechanism. Our pricing is derived from on-chain liquidity rather than external oracles.

Price differences are expected. Our prices may appear lower because they reflect actual liquidity conditions.

For each token:

  • Routed through 3 stablecoins

  • Each stablecoin evaluates 3 shortest routes

  • Total: 9 route evaluations

  • The maximum output is selected as the “sell_usd” price

  • Then used as input to compute “buy_usd” across the same routes

Prices may deviate from aggregated market prices due to limited liquidity depth on Rootstock.

Summary:
Oracle prices reflect global market references, while our prices reflect executable on-chain prices under current liquidity conditions.

Note:
USD pricing is only for UI reference and does NOT affect actual routing or execution.
Removing USD display does not impact swap functionality.

In Milestone 1, we upgraded the pricing system. However, due to:

  • limited liquidity

  • high BTC price

  • lack of split routing

BTC price quotes still deviate from broader market prices.

Even oracle-based pricing may show inconsistencies:

  • 0.1 BTC = 6700 USDT

  • but 1 BTC ≠ 67000 USDT

This is due to liquidity depth and price impact.

In the future, we plan to improve BTC pricing using simple split-quote methods, such as:

  • 0.5 BTC via route1

  • 0.5 BTC via route2

to better approximate market pricing.

1 Like
59

@SwaptoX Thank you for the Milestone 1 report — the dApp and demo look clean.

One thing I wanted to flag: the Rootstock Block Explorer uses SolidityScan to assign a Security Score to contracts via AI-based vulnerability scanning. For context, the Uniswap v3 pool scores 54.08/100 — and SwaptoX’s Router Contract scores 53.15/100.

Since your report highlights that the router contract has been audited, I wanted to surface this for transparency. A score in this range doesn’t necessarily indicate a problem, but it’s worth addressing directly — either by clarifying the scope of the existing audit, noting known limitations of the SolidityScan methodology, or outlining any plans to remediate flagged issues.

Thanks again for sharing your Milestone 1 report.

1 Like
60

Thanks for the detailed Milestone 1 report, @SwaptoX. The deployment is clearly live and the over-delivery on integrations (Sovryn, ElkV2) is appreciated.

A few concerns we’d like to raise.

Split routing gap is material on Rootstock. The report acknowledges that OpenOcean achieves $50-100 better output on 1 BTC swaps due to split routing. On a low-liquidity chain like Rootstock, this disadvantage is amplified, not diminished. The claim that trades below ~$2,000 are “comparable or sometimes better” needs independent verification. Given that routing quality is the core value proposition of an aggregator, and split routing is currently planned for after Milestone 2-3, we think it should be reprioritized.

The rationale for keeping the Entered contract closed-source is weak. The Entered contract sits between the Router and liquidity pools and handles user funds mid-execution. Calling it a “stateless execution contract” does not change the fact that it processes token transfers on behalf of users. We would strongly recommend open-sourcing it.

Router contract owner privileges are broader than disclosed. We reviewed the verified Router contract on Blockscout. The owner can redirect all swap execution to a different contract at any time, enable fees up to 30bp without notice, and withdraw any token held by the contract. Even after renounceOwnership() is called, the designated wallet address retains withdrawal capability. The forum discussion has framed the contract as “non-custodial” and “trust-minimized,” but that framing is overstated given these admin capabilities. We would appreciate a clear disclosure of owner privileges and a concrete plan for constraining them.

Separately, the report references the Router as “audited,” but no audit report has been shared. Could you clarify whether a formal third-party audit has been completed?

1 Like
61

@Axia @Tane
Clarification:

We sincerely apologize for the confusion. The Router contract has not yet undergone a security audit.

The previous statement was incorrectly translated during AI-assisted editing. The intended meaning was that the Router contract is open source and scheduled for future audit, rather than already audited.

We will address all other questions within 24 hours. Thank you for your patience and understanding.

1 Like