Thanks for the clarification on the audit status, @SwaptoX. We appreciate the honesty.
Given that the Entered contract is also unverified on Blockscout, we think open-sourcing it and incorporating a formal audit into one of the remaining milestones would go a long way toward building the trust needed for Milestone 3’s adoption targets.
Looking forward to your responses on the other points.
@Tane**, thanks for your detailed review and questions.**
I am happy to reprioritize split routing. For example, Milestone 2 could include:
Split routing
Transaction history display
Token risk warnings
Permit-based approvals
Other improvements
You also suggested including a security audit as part of the milestones, which would increase both timeline and cost.
I appreciate Rootstock’s generous support. I am willing to prioritize split routing and introduce a security audit milestone, and would like to hear other reviewers’ opinions on this adjustment.
If Entered is open-sourced at this stage, one issue is that users could directly bypass the Router and interact with Entered to execute swaps.
As adoption grows, it is likely that arbitrage bots or advanced users would deploy their own Router + Entered setup to avoid Router fees, or even directly interact with Entered. This could lead to loss of routing fee capture and potential API abuse.
Not open-sourcing the execution layer is also aligned with current industry practices. For example, large aggregators typically not only keep their executor contracts closed-source, but also apply signing/encryption to their routing data (“SwapData”) to ensure execution happens only through their system.
KyberSwap executor (not open source):
https://basescan.org/address/0x63242a4ea82847b20e506b63b0e2e2eff0cc6cb0#code
It is explicitly labeled as: KyberSwap: Aggregator Executor V3
OpenOcean executor (not open source):
https://rootstock.blockscout.com/address/0x804c44Cec51b24E9F20447F8D21ba153403280D1
This can be observed in swap transaction traces where all token transfers pass through this address
OpenOcean entry contract:
https://rootstock.blockscout.com/address/0x6352A56caaDc4F1e25cd6c75970fA768A3304E64
There are two potential risks (note: Router enforces amountMinOut for safety):
Executing unrelated logic
Entered could theoretically execute operations unrelated to the swap (e.g., hidden arbitrage or other profit strategies), leading to unnecessary gas costs.
Result: unusually high gas usage or unexpected token transfers on-chain.
Retaining surplus output
Entered could retain any output exceeding amountMinOut, capturing additional value while still ensuring the swap succeeds.
Result: small, unexplained token discrepancies in transaction records.
Given the above risks, I have considered open-sourcing Entered. However, at this stage:
There is no effective way to prevent bypassing the Router
Our routing data (“SwapData”) is not yet signed or encrypted
Even without protocol fees, this could lead to API abuse (especially on chains like Base, where arbitrage bots are highly active)
Therefore, I believe that open-sourcing Entered at this stage introduces more risk than benefit.
We previously committed to providing at least one year of free swaps for Rootstock users. I would like to clarify this commitment:
In addition:
During this period, we will:
Explore signing/encryption mechanisms for SwapData
Implement API rate limiting and abuse protection
amountMinOut to EnteredPassing amountMinOut to Entered may be misunderstood; its purpose is gas optimization.
If the final liquidity source is Uniswap V2:
We must call getAmountOut before execution. If the result is below amountMinOut, the transaction reverts early, avoiding unnecessary swaps.
If it is Uniswap V3:
The actual output is known during the callback. If it is below amountMinOut, the transaction reverts immediately, avoiding unnecessary transfers.
This is a trade-off between execution verification and gas efficiency, and the current design prioritizes reducing unnecessary gas consumption for users.
The main user-impacting permissions are:
Setting protocol fees (up to 0.3%)
Updating the Entered contract address
A maximum fee of 0.3% is within industry norms. Most aggregators charge around ~0.25%, sometimes less visibly.
We also support fee exemptions for specific tokens. In the future:
Default fee: 0.2%
Native token swaps (WRBTC): fee-free
Entered may require upgrades over time, for example to integrate new liquidity sources or improve execution logic.
Any funds held in the Router are protocol fee revenues, which belong to the project and should be withdrawable by the owner.
Some protocols transfer fees immediately during swaps (increasing gas cost per transaction), while others accumulate fees in the contract and withdraw periodically.
Immediate transfer → higher per-swap gas cost
Accumulated withdrawal → more gas-efficient for users
We chose the latter to optimize user costs.
To mitigate risks related to admin privileges, I plan to redeploy the Router contract in Milestone 2 with:
A 72-hour timelock on all onlyOwner functions
Restriction: only one admin action can be executed within each 72-hour window
Protocol fee lock:
After these changes, we will proceed with the next phase of the security audit.
@axia, thank you for raising this — and we apologize for the earlier terminology confusion. To clarify, the contracts have not yet undergone a formal third-party audit.
Regarding the SolidityScan report, we view AI-based scores as a baseline reference for identifying common patterns, rather than a substitute for a comprehensive audit. The fact that SwaptoX’s Router (53.15) is in a similar numerical range to Uniswap V3 pools (54.08) suggests that the contract follows broadly comparable structural patterns, but we fully acknowledge that this does not imply equivalent security guarantees, especially without formal auditing and production history.
SolidityScan report:
https://solidityscan.com/qs-report/f9d7451790aa95e564f40698996ac02d/6220a6c11e8b3835/6ab686dc137ee3cf
1. Solidity Version
We are currently using v0.8.26, which is stable and widely adopted. We plan to upgrade to the latest compiler version during the Milestone 2 contract redeployment.
2 & 5. Owner Privileges & Special Access
These permissions are required for system maintenance and liquidity integration during the current phase.
To mitigate centralization risk, we plan to introduce:
A 72-hour timelock on all admin operations
Restrictions on execution frequency (one admin action per time window)
We are also evaluating additional control mechanisms (such as multi-party authorization) as the system matures.
3. Hardcoded Addresses
The RBTC and WRBTC addresses are intentionally hardcoded. This is a deliberate design choice to:
Prevent accidental or malicious redirection of core liquidity paths
Improve gas efficiency by avoiding unnecessary storage reads
4. Ownership Interface (owner())
The current Router uses a simplified access control structure for gas efficiency.
We recognize that adopting a standard owner() interface improves transparency and tooling compatibility. In the next version, we will align with the OpenZeppelin Ownable standard.
These findings largely reflect early-stage design trade-offs between flexibility, gas efficiency, and administrative control.
We have identified the relevant areas for improvement and will address them in the Milestone 2 contract upgrade, prior to initiating the formal audit process.
Thanks for the detailed response, @SwaptoX. We verified the claims about KyberSwap and OpenOcean executor contracts, and they check out. The industry practice argument is fair, and the commitment to open-source Entered before enabling fees is a reasonable compromise.
On the audit: we want to flag something for the broader group. The original $15K proposal included no audit scope or budget. The framing now is that adding an audit “would increase both timeline and cost,” but for infrastructure that routes token transfers through an unverified closed-source contract, an audit is not optional. @Curia raised the audit question early in this thread, and @Axia and @ChronoTrigger both flagged related concerns around verifiability and risk. We think this deserves a broader discussion: should audits be a standard milestone requirement for grants involving smart contract infrastructure, a shared ecosystem resource, or handled some other way?
More broadly, several commitments here, open-sourcing Entered, deploying the timelock, locking fees until June 2027, take effect after grant completion. We think key items like the timelock and Entered open-sourcing should be tied to milestone approval rather than left as future promises with no enforcement mechanism.
Milestone Adjustment
Thanks to @Tane for highlighting three key issues:
Excessive standalone privileges of the Router
Priority of split routing
Formal audit planning
I agree that these are critical concerns. Below are the adjustments and clarifications.
(Estimated 20–30 days)
Develop split routing algorithms and core routing logic.
(Estimated 7 days)
Upgrade token USD pricing logic to split-based quoting, ensuring displayed prices better reflect actual swap execution prices.
(Estimated 5 days)
Fully migrate API to Redis caching and integrate Cloudflare global acceleration.
Current quote latency: 3–4 seconds → Target: 1–3 seconds.
(Estimated 7 days) UI improvements:
Display transaction history
Support permit-based approvals
Redesign routing display module (to support split routing visualization; current display only reflects single-path routes)
(Estimated 7 days) Router contract governance upgrades:
The Entered contract becomes upgradeable only (e.g., v2, v3), and deployed versions cannot be overwritten
Introduce a 3-wallet multisig, requiring 2-of-3 signatures for any admin operation
Implement a 72-hour timelock for all admin functions (“request + confirm” pattern; confirmation must be executed by a different signer to mitigate single key compromise risk)
Extend the protocol fee timelock on Rootstock: no protocol fee changes allowed before 2028 (based on current timeline, all milestones are expected to complete by September 2026)
Audit planning (to be delivered in Milestone 3):
Engage multiple audit firms to obtain quotations
Apply for third-party audit grants (e.g., https://atlas.optimism.io/missions/audit-grants)
Outcome: determine audit scope, cost, availability of external funding, and finalize the audit plan.
Milestone 2 will define and establish a concrete audit plan (scope, provider, and timeline), which will be a prerequisite for execution in Milestone 3.
This milestone addresses the priority of split routing and significantly mitigates the risks associated with Router administrative control. It also delivers a concrete audit plan for Milestone 3.
The multisig structure will initially be managed by the core team, with additional signers introduced over time to reduce unilateral control risk.
The main challenge of this milestone lies in the split routing algorithm, as there is no standard solution and it requires extensive computation to determine optimal path allocation and proportions.
To validate the implementation:
A public comparison page will be built using both SwaptoX API and OpenOcean API
Identical inputs (token pair and amount) will be used for fair comparison
At least 30 different test scenarios will be included, covering:
Various trade sizes (e.g., 0.1 BTC, 0.5 BTC, 1 BTC, 2 BTC, etc.)
Multiple token pairs (e.g., BTC → USDC, BTC → USDT, USDT → BTC, etc.)
Each page refresh triggers a new round of live quotes
Tests will be conducted across multiple blocks and time intervals to reduce the impact of short-term market fluctuations
SwaptoX demonstrates competitive routing performance compared to leading aggregators across multiple trade sizes.
This includes:
Comparable or better average output
Positive or near-neutral median performance
A meaningful share of scenarios (across varying trade sizes and token pairs) where SwaptoX achieves equal or better results
No significant negative deviation in large trades
The comparison page will be publicly accessible for anyone to verify results.
Milestone 2 Timeline: 45–60 days
Requested Funding: $6,000
Aligned with Milestone 2 from “Redefined Milestones: V2.1”, now redefined as Milestone 3.
Additionally:
We will build a dedicated interface using the Mini-SDK:
mini.swaptox.com (currently not live)
This interface will:
Provide a simplified and complete swap experience
Be optimized for mobile usage
Serve as the primary entry point for:
Telegram bots
Farcaster Mini Apps
Native DEX aggregator app integrations
For growth in Milestone 4, distribution will prioritize Telegram bots alongside SDK adoption.
Timeline: 30–40 days
Requested Funding: $4,000
Aligned with Milestone 3 from “Redefined Milestones: V2.1”, now redefined as Milestone 4.
This revision increases the total funding request by $3,000 compared to the original proposal.
The expanded scope introduces additional engineering complexity, particularly in:
Split routing implementation (multi-path optimization and allocation logic)
Router contract security enhancements (multisig, timelock, and stricter upgrade constraints)
These components were not part of the original implementation.
The changes significantly improve execution quality and protocol security, and therefore require additional development effort and time.
This updated proposal will enter a 7-day discussion period before proceeding to on-chain voting.
Thanks for the revised milestones, @SwaptoX. The adjustments to Milestone 2 address the concerns we raised, and the split routing validation via a public comparison page is a good accountability mechanism.
We’re supportive of Milestone 2 as scoped. We’d like to hear other delegates’ views on Milestone 4 and the overall budget increase before the on-chain vote.
@Tane Thanks for the support.
If I understand correctly, the main concern is whether an audit should be completed before M4, and how the potential audit cost may impact the overall budget.
I agree that relying on external audit funding introduces uncertainty. Depending on the outcome of external options, it may be necessary to further discuss how audit should be scoped and funded within the Rootstock context.
At the current stage, since the Router contract is still undergoing modifications, it is difficult to define an accurate audit scope or cost estimate.
That said, audit preparation has already been incorporated into the development process. For example:
As mentioned, audit planning is included in Milestone 2. By the end of M2, I will be able to provide:
Given this, one possible approach could be to revisit the audit budget discussion after M2, when more concrete data is available.
Happy to hear other delegates’ thoughts on how best to structure this.
@SwaptoX We’ve reviewed the Rootstock integration in your dApp, it looks good and offers a smooth, easy-to-follow user experience. All deliverables for Milestone 1 have been completed as promised.
We’re voting in favor of Milestone 2. We previously raised concerns around the audit, as @Tane mentioned, so it’s good to see this now being addressed, with audit planning included in the next milestone.
For Milestone 4, we would like to have a more detailed breakdown of the marketing plan.
Could you clarify how each of these budgets will be used in practice, what specific activities you plan to run, and how you will measure the effectiveness of each? Also, how do you plan to ensure that the growth is sustainable and not purely driven by short-term incentives, and that user retention does not drop after the campaigns end?
@Curia Thank you for your support.
Regarding the growth milestone, we agree that it is important to define KPIs based on reasonable assumptions and continuously validate them during execution. While our current focus remains on development, we would like to further clarify how the budget in Milestone 4 will be used in practice:
This portion will be used to guide user behavior rather than sustain volume through subsidies, including:
First-time user incentives (to reduce onboarding friction)
Incentives for higher-value swaps
Incentives for repeat users (to improve retention)
We will track:
Cost per active trader (estimated ~$6–10)
Repeat rate
Volume per user
The goal of incentives is to:
bootstrap user behavior, not to sustain short-term trading volume
This portion will be used to support the distribution and adoption of our Mini-SDK, including:
Providing technical support and integration assistance
Offering protocol fee sharing incentives (30%–50% tiered model)
Supporting integrations with wallets, DeFi tools, and other applications
For example, once a partner brings 300 trading users, they can permanently unlock a 50% protocol fee share.
We will measure:
Number of integrations
Volume generated from integrations
Number of users acquired via integrations
The objective here is to build:
recurring volume driven by integrations, rather than relying on incentives
This will focus on targeted distribution and conversion, rather than broad exposure:
Telegram Bot distribution (via mini.swaptox.com)
Mini-app ecosystems (e.g., Farcaster)
Co-marketing with integration partners
We will track:
Conversion rate (visit → swap)
Cost per user
Post-campaign retention
We place strong emphasis on avoiding short-term, incentive-driven growth. Long-term growth will primarily come from:
Product competitiveness (better routing and price execution)
Sustainable volume from SDK integrations
Organic traffic from SEO and distribution channels
For long-term growth, we have a clearer plan to ensure sustainable traffic sources across three main channels:
Mini-SDK distribution and integrations
mobile distribution via mini.swaptox.com
SEO-driven traffic via app.swaptox.com
As mentioned above, we aim to provide a lightweight and high-performance SDK to create a stable traffic entry point.
For integration partners:
Users can perform swaps directly within partner applications without being redirected externally
Partners receive 30%–50% protocol fee share
Once a partner brings 300 trading users, they permanently unlock a 50% revenue share
This creates a strong incentive alignment and encourages long-term integration.
We will actively promote SDK distribution to establish a sustainable and recurring traffic source.
We will provide a mobile-optimized interface via mini.swaptox.com, which integrates the SDK and therefore has low development overhead.
This interface is designed primarily for:
Telegram Bot distribution
Social sharing scenarios
Mini-app ecosystems such as Farcaster
Potential embedding in native apps
The goal is to provide a:
simple, fast, and easily shareable swap entry point
By optimizing for mobile usage and social distribution, this channel can efficiently capture incremental users from messaging and social platforms.
As part of supporting more advanced routing logic and scalable user acquisition (e.g., SEO and integrations), the application architecture has been upgraded accordingly:
With Milestone 2 introducing:
split routing (more complex route visualization)
SDK modularization (swap input extracted as a reusable component)
the existing frontend structure becomes less suitable. Upgrading the architecture at this stage helps:
avoid repeated refactoring in later stages
support more scalable UI and feature expansion
Slower initial page load
Poor SEO (only the homepage is indexed)
Use of /#/ routing, which may confuse users
Limited compatibility with broader Web3 ecosystem standards
We upgraded to a React / Next.js architecture to:
Enable server-side rendering (SSR) for better SEO
Improve initial load performance
Provide a more standard and scalable Web3 frontend structure
Support multi-language and dynamic routing
Example routes:
app.swaptox.com/[locale]/[chain]
app.swaptox.com/en/rootstock
app.swaptox.com/zh-CN/rootstock
app.swaptox.com → auto redirect → /[locale]/[chain]
With this architecture:
Token and liquidity pool pages can be indexed by search engines
The application can scale to hundreds of indexable pages
Search engines can access near real-time token and pricing data
This enables long-tail organic traffic, which compounds over time and does not rely on incentives.
This upgrade was initiated immediately after defining Milestone 2 and is now largely completed.
It does not impact the delivery timeline of Milestone 2.
We await with interest the details of the security audit plan committed to in Milestone 2 -to be delivered in Milestone 3-. Could you let us know which audit firms you plan to contact? This is a very sensitive issue, and we expect that they will be companies with a recognized reputation.
@SEEDGov Thank you for your question.
Our current plan is to prioritize applying for an audit grant through Optimism, as we are already deployed on Base and meet the eligibility criteria:
https://atlas.optimism.io/missions/audit-grants
In practice, this involves working with audit firms from Optimism’s approved audit partner list, who can both conduct the audit and assist with the grant application process:
https://hackmd.io/@wbnns/superchain-audit-service-providers
In parallel, we also plan to directly reach out to several well-recognized audit firms to obtain quotations and evaluate scope and availability. Potential firms we are considering include:
Spearbit
Zellic
We believe combining the Optimism audit grant pathway with direct outreach to established audit providers will allow us to:
Compare audit scope and pricing
Ensure auditor availability within our timeline
Maximize the chances of securing external funding support
Based on these inputs, Milestone 2 will finalize the audit plan (scope, provider, and timeline), which will then be executed in Milestone 3.
Thank you for your response and clarification on this matter. We have voted in favor of approving Milestone 1 and releasing the funds for Milestone 2, in accordance with the rationale provided in our delegation thread.
Hey @SwaptoX , we have voted FOR your proposal on chain, because it perfectly balances building better tech with locking down the protocol’s security. Looking forward for the audit planning data you will gather for milestone 3 . All the best for the Optimism audit grants!
thanks for the update @SwaptoX. For M2, we voted “For” as the rationale below:
Thank you all for your support.
Milestone 2 has now reached quorum, and I will begin work on it immediately. The estimated delivery timeline is 45–60 days, with a latest completion date of June 15.
As Milestone 2 includes a relatively substantial scope, I will provide a mid-milestone progress update (around one month in) to keep everyone informed.
Thanks again for your support.
Hi team, quick question regarding proposal execution.
When attempting to execute the transaction, I received the following error:
“The transaction will fail because the treasury does not have enough rBTC.”
From the treasury dashboard, it seems the total grant balance is sufficient, but the active rBTC balance may currently be lower than the required payout for this milestone.
Just wanted to check whether there is a planned transfer or rebalance from the main treasury to the active pool for execution.
Thanks!
Hi @Tane,
Following your feedback regarding centralized ownership risk, I’ve redesigned the admin model for SwaptoX to improve decentralization and security.
Originally, SwaptoXRouter used a single owner model.
I initially considered adding multi-admin logic directly into SwaptoXRouter.
However, this approach caused the contract size to exceed the 24KB limit, making deployment impossible.
In fact, the current Router is already close to the limit, and I had to remove some view functions to fit within constraints.
Instead of embedding admin logic into the Router, I introduced a separate governance contract:
SwaptoXTimelock
This separation:
All admin actions follow:
Cancellation rules:
This ensures:
The guardian is NOT part of normal governance.
It is only designed for extreme scenarios, such as:
Implication:
Once activated:
Additionally:
This design:
Please let me know if you have any concerns or suggestions.
Code:
Hi @Axia , my proposal has been approved for about two weeks, but it is currently not executable due to insufficient Active balance in the Grants treasury.
I also noticed that @jxlabs proposal seems to be in a similar situation.
Since I’m not sure when this will be addressed, the uncertainty is starting to affect my planning on the development side.
Could you please help check with the team regarding the status of treasury rebalancing for execution?
Thanks a lot!
Hi @SwaptoX Apologies for the inconvenience. Let me check with the team and get back to you asap.
Hey @SwaptoX the proposal will be be executed by end of this week. If you have any questions about payments in the future, you can reach out to @tamlerner directly.
