Thanks for submitting the Milestone 2 delivery report.
I completed an independent review of the milestone against its approved deliverables, including a provisional FES and SWOT assessment.
While meaningful technical progress has been made, I believe M2 should remain open until the outstanding testing, governance deployment and audit-planning requirements are addressed.
I’m sharing the full analysis here for transparency and welcome any corrections or additional evidence from the team.
@Tane @Kaf_Anode @SEEDGov @Curia @Axia @ChronoTrigger
First, regarding the possibility of obtaining audit funding through Optimism:
Although the Optimism audit grant application page is still marked as “Open”, multiple audit firms participating in the program have confirmed that the current funding round has already ended. At this time, there is no announced schedule for when the next round of audit grants will become available.
For other audit companies that advertise audit funding opportunities, these appear to function primarily as marketing channels rather than confirmed grant programs, so they should only be considered as reference.
Below are the quotations received from multiple audit firms.
Quotation document: https://cdn.swaptox.com/audit-quoter/guardian.pdf
Price: $3,500
Audit duration: 1 day
Scope: SwapToXRouter.sol (407 LOC)
Highlights:
Includes a $100,000 public bug bounty campaign.
SwaptoX would have the opportunity to participate in this public security bounty program.
Minimum budget accepted: $10,000
PashovAuditGroup customizes both the audit scope and audit depth according to the available budget. A detailed proposal can only be provided after the audit budget has been determined.
Quotation document: https://cdn.swaptox.com/audit-quoter/omniscia.pdf
Price: $2,275
Audit duration: 1.5 engineer-days
Scope: SwapToXRouter.sol (407 LOC)
Highlights:
Scope: SwapToXRouter.sol (407 LOC)
Description:
Estimated effort: 3 days, with 2 reviewers, billed at $2.4k/day = $7.2k total. We can apply a 20% FailSafe Grant, bringing the final audit fee to $5.76k.
Scope:
SwaptoXRouter.sol (407 LOC)
NSLOC: 407
Number of LSRs: 2
Start Date: 28th May
Duration: 3 Days
Cost: $10,000
Partial audit requested - we have to pass on this option it doesn’t appear safe since those functions call other functions which modify internal state etc, it becomes a mess and risky to figure out exactly what to audit and what not to audit
Quotation document: https://cdn.swaptox.com/audit-quoter/MixBytes.pdf
Scope: SwapToXRouter.sol (407 LOC)
Price: $12,000
Audit duration: 3 days
Highlights:
Performs an additional verification after mainnet deployment to ensure the deployed bytecode exactly matches the audited source code.
MixBytes has extensive experience auditing both DEX aggregators and liquidity protocols.
Example audit experience includes:
OKX Aggregation Router
1inch Aggregation Router V4
Velodrome
SushiSwap
Quotation document: https://cdn.swaptox.com/audit-quoter/Zellic.pdf
Audit effort: Two security engineers for half a calendar week (0.7 engineer-weeks total)
Scope: SwaptoXRouter.sol (407 LOC)
Price: $14,000
Quotation document: https://cdn.swaptox.com/audit-quoter/Hacken.pdf
Audit duration: Four working days with two full-time Senior Auditors.
Audit fee: $18,250 (fixed price)
Scope: SwaptoXRouter.sol + SwaptoXTimelock.sol (1,080 LOC total)
Security Badge:
After the audit is completed, the project may display the “Audited by Hacken” badge on CoinGecko and CoinMarketCap, together with the published audit report.
Marketing Support:
Includes complimentary promotional support across Hacken’s social media network (300k+ followers), AMA sessions, case studies, and additional marketing exposure.
Notes:
Hacken considers SwaptoXRouter.sol and SwaptoXTimelock.sol to be tightly coupled.
They declined to audit only the Router contract, stating that both contracts must be audited together to provide sufficient security assurance.
Based on further discussions, an estimated 20% discount may be available (USD 3,650), reducing the total cost to approximately $14,600.
Hacken is also a well-established audit firm with significant experience auditing aggregators and liquidity protocols.
Audit duration: 2 days
Scope: SwaptoXRouter.sol (407 LOC)
Price: $7,000
A. Full audit — entire SwaptoXRouter.sol (ERC20Helper lib + OwnerContract + InviterContract + SwaptoXRouter + interfaces)
• Audit duration: 4 days
• Fix review: 1 day
• Effective nLOC: 403
Cost: $24,000
B. Limited scope — swap + native2Wrapped + wrapped2native + transitive deps
• Audit duration: 2 days
• Fix review: 1 day
• Effective nLOC: ~250 (incl. _swap, safetyTransferIn, ETH2token/token2ETH/token2token, nonReentrant/ensure modifiers, bindInviter, ERC20Helper.permit)
Cost: $14,400
Audit duration: 0.5 week
Scope: SwaptoXRouter.sol (407 LOC)
Price: $15,000
All audit quotations requested were limited to SwaptoXRouter.sol and did not include SwaptoXTimelock.sol.
Among all audit firms contacted, only Hacken required SwaptoXTimelock.sol to be included within the audit scope.
The original reason for requesting quotations only for the Router contract was to control audit costs. In addition, I believe that ensuring the security of the user-facing functions (swap, native2Wrapped, and wrapped2native) is sufficient to protect user funds. Even if an issue were discovered in SwaptoXTimelock, it would not directly place users’ assets at immediate risk.
If SwaptoXTimelock is later included within the audit scope, a completely new quotation will be required.
Since audit funding still needs to be discussed separately and submitted through an independent funding request, I am currently unable to commit to any specific audit provider.
Once an audit budget has been determined, I will be able to communicate much more efficiently with the audit firms and provide a final recommendation based on both security coverage and cost effectiveness.
Regarding the SwaptoXEntered contract:
Although this contract is ultimately responsible for interacting with liquidity protocols and transferring user assets, I do not believe it requires an independent audit.
Auditing SwaptoXRouter is sufficient to guarantee the security model protecting users, while SwaptoXEntered itself is intentionally designed to be replaceable. As new liquidity protocols are integrated, this contract may need to be modified and redeployed without affecting the Router.
Furthermore, user funds are ultimately handled not only by SwaptoXEntered, but also by external liquidity protocols. It is impossible to guarantee that every third-party liquidity protocol has been audited or is completely risk-free. Nevertheless, the aggregator can safely route through them because SwaptoXRouter ultimately enforces the user’s AmountMinOut protection.
For this reason, the security boundary should focus primarily on the Router contract rather than requiring every execution contract or external liquidity protocol to be audited.
I will respond to the remaining questions as soon as possible.
Thank you all for taking the time to review the milestone and for your valuable feedback and suggestions.
@Tane @krngill @pgov @Kaf_Anode
@Tane , you’re absolutely right.
Regarding the SwaptoXTimelock multi-admin contract and the fee lock until 2028, these features cannot be verified until the contracts are actually deployed.
However, after reviewing the current development plan, I believe it is more appropriate to validate them during Milestone 3. Milestone 3 marks the beginning of the growth phase, where all production contracts will be finalized and deployed permanently.
Therefore:
the governance upgrade and the 2028 fee lock move to M3.
Regarding the requirement for 30 swap scenarios, my understanding is that these scenarios refer to different trading pairs and different trade sizes.
I apologize for not explaining this more clearly in my previous update.
I believe the amount of testing I have performed already meets or exceeds this requirement.
The comparison page allows selecting different tokenIn assets and different amountIn values for batch testing. A single execution already includes multiple trading pairs, so I’m not entirely sure whether one batch execution should be counted as one scenario or multiple scenarios.
During development, I spent approximately five days performing comparison testing, with well over 30 individual tests covering different tokens and input amounts.
Since SwaptoX generally achieved better pricing, I intentionally deducted an additional 0.1% from SwaptoX’s quoted output to simulate the protocol fee before making comparisons, making the benchmark more conservative.
Based on these tests, my conclusion is that SwaptoX performs better overall.
Regardless of the input amount or the selected tokenIn, SwaptoX consistently achieves a win rate above 60%.
For larger trades (for example, swapping 2 BTC), OpenOcean frequently returns routes that cannot successfully simulate, while SwaptoX continues to produce executable routes.
Based on these results, I believe SwaptoX has reached a level where its performance shows no meaningful gap compared to OpenOcean, and in many cases performs better.
If you consider the current comparison page to be an acceptable benchmarking method, then running it at any time should continue to demonstrate a win rate above 60% for SwaptoX.
I believe the remaining discussion is not about the results themselves, but about defining the benchmarking methodology—specifically how the comparison page should be evaluated and how the results should be interpreted.
If the current methodology is considered acceptable, then I believe Milestone 2’s requirement of achieving performance comparable to OpenOcean has been satisfied.
If you have a better or more standardized benchmarking methodology, I would be very happy to adopt it.
Redis caching has already been implemented for the API.
Based on observations from the Railway deployment, most API requests complete in approximately 1 second, although a small percentage may take 4–7 seconds.
This latency is primarily affected by two factors:
The RPC provider (currently using Alchemy’s paid RPC service).
The geographic location from which the API request originates.
In addition, split routing now performs more RPC requests than the previous routing algorithm, so although backend optimizations have been completed, the additional RPC workload offsets much of the latency improvement.
Cloudflare global acceleration has not yet been enabled. This is a relatively straightforward deployment task that mainly requires binding the domain and enabling the service.
However, since the new API has not yet been integrated into the frontend, I would like to move the Cloudflare validation to Milestone 3, when the production deployment is completed.
This task has not yet been completed.
Now that split routing has been implemented, adapting the pricing engine is relatively straightforward.
At the moment, the quote server still needs to support the existing API and UI.
Milestone 3 will introduce the new React/Next.js frontend architecture, so I would also like to move validation of the updated pricing engine to Milestone 3.
I will continue responding to the remaining questions as soon as possible.
Thanks for the follow-up, @SwaptoX. Recording the governance upgrade and the 2028 fee lock as moving to Milestone 3 is what we asked for, so we consider that item settled for this milestone.
On benchmarking, we agree with your framing: the open question is methodology, not results. Put simply, our suggestion is this: make the testing you already did reproducible. Publish the scenario set in advance, run it more than once, and post the results rather than the conclusion, judged against the success criteria in the scope. If the numbers hold where you describe them, we would treat the validation KPI for this milestone as met.
@Kaf_Anode , thank you for taking the time to prepare such a detailed review and for providing constructive suggestions.
I’d like to clarify several points below.
Regarding Cloudflare global acceleration for the API and improving USD price calculation using split routing, I believe it is more appropriate to validate both items during Milestone 3, in line with the current development schedule.
At present, the original API v1 routing service and the new API v2 split-routing service are deployed on separate servers.
I would prefer not to immediately shut down the v1 quote server, migrate all traffic to v2, or provision an additional dedicated quote server for API v2 before the frontend migration is complete. Doing so would introduce unnecessary work and infrastructure costs while providing little practical benefit.
This adjustment is mainly a consequence of moving the frontend migration to Milestone 3, so I believe these tasks should be validated together at that stage.
Regarding the Timelock contract and the protocol fee lock until 2028, I also believe validation should take place in Milestone 3, as both may still require modifications during development or as a result of the security audit.
Regarding the growth metrics mentioned in the review, my current focus remains entirely on development. No marketing or user acquisition activities have been conducted yet, and the project roadmap already includes dedicated growth milestones. User growth activities are scheduled to begin in Milestone 4.
For the work items being moved from Milestone 2 to Milestone 3, I will publish an updated Milestone 3 scope before development begins. The new scope will clearly distinguish between the original Milestone 3 deliverables and the items deferred from Milestone 2.
Although this increases the amount of work included in Milestone 3, I am not requesting additional funding. The only adjustment that may be necessary is a longer completion timeline, which I will explain in detail when Milestone 3 officially begins.
Since there is currently no standardized benchmarking methodology, I believe the existing public comparison page already provides a fair representation of real-world swap performance.
I acknowledge that individual tokens may occasionally produce different results due to market conditions and liquidity changes. In some cases SwaptoX may perform better, while in others OpenOcean may temporarily achieve a better quote.
However, based on extensive testing, the overall performance consistently favors SwaptoX.
To avoid overstating the results, I would like to make the following conservative commitment:
Using the current public comparison page and the current liquidity conditions, SwaptoX’s
RealAmountOutshould outperform OpenOcean in at least 55% of all tested routes.
Although the observed win rate is typically above 60%, I intentionally use 55% as the commitment threshold to provide a conservative margin.
Reviewers are welcome to verify this claim at any time by using the public comparison page with any supported tokenIn asset and any input amount.
If future verification shows that SwaptoX’s RealAmountOut falls below OpenOcean, or that the overall win rate drops below 55%, I would consider that evidence of significant performance variation and acknowledge that further optimization would be necessary.
I am confident in this commitment and welcome independent verification, as repeated testing has consistently produced results above this threshold.
Below are the latest benchmark results collected today. Each benchmark session was conducted over approximately two hours.
| tokenIn | Scope | Trade Size | RealAmountOut Win Rate |
|---|---|---|---|
| WRBTC | All 43 supported tokens | 1 WRBTC (~$64,000) | 86% |
| WRBTC | All 43 supported tokens | 0.1 WRBTC (~$6,400) | 83% |
| USDC.e | All 43 supported tokens | 100,000 USDC (~$100,000) | 81% |
| USDT | All 43 supported tokens | 20,000 USDT (~$20,000) | 81% |
| RIF | All 43 supported tokens | 200,000 RIF (~$13,000) | 79% |
The Base network has significantly deeper liquidity, reducing the impact of liquidity shortages and resulting in more stable benchmark data. For this reason, I believe these results provide useful supplementary validation.
| tokenIn | Scope | Trade Size | RealAmountOut Win Rate |
|---|---|---|---|
| WETH | All 412 supported tokens | 1 ETH (~$1,600) | 69% |
| USDT | All 412 supported tokens | 50,000 USDT (~$50,000) | 73% |
| USDC | All 412 supported tokens | 100,000 USDC (~$100,000) | 66% |
Thank you for raising these questions, and I apologize for the delayed response.
I’d like to clarify both the timeline of grant applications and my long-term vision for SwaptoX.
The applications to other ecosystems were not initiated after receiving Rootstock funding.
When the first MVP of SwaptoX was completed on August 28, 2025, my initial plan was to build on Base. At that time, I only applied for the Base ecosystem grant. After waiting more than two months without receiving any response, I submitted applications to Arbitrum and Avalanche. Avalanche declined the proposal, while Arbitrum never responded.
At that point, I realized that large ecosystems already had mature aggregator solutions, making it difficult for an independent project like SwaptoX to gain attention. I therefore shifted my focus toward ecosystems where infrastructure was still developing and where an aggregator could provide greater value.
Following that decision, I submitted proposals to several ecosystems, including Astar, Conflux, 0G and Rootstock.
The timeline is as follows:
Astar: December 15, 2025
Conflux: December 15, 2025
0G: December 26, 2025
Rootstock: January 9, 2026
I actively worked with the Astar community for several weeks, but after their reviewers concluded that current liquidity was too limited to justify an aggregator, I decided not to continue with an on-chain vote.
Rootstock was actually the last ecosystem I applied to, but it was the first to actively engage in discussions, provide constructive feedback, and work together to define realistic milestones. Milestone 1 was officially approved on March 2, 2026.
Both Conflux and 0G responded much later.
Conflux requested additional information on March 12, 2026.
0G requested a technical meeting on April 23, 2026.
By that time, I was already fully committed to delivering the Rootstock milestones.
Since receiving Rootstock funding, I have not submitted any new grant applications to additional ecosystems. My priority has been completing the work committed to the Rootstock Collective.
Conflux and 0G remain potential opportunities because those discussions began before Rootstock funding was approved. However, I have intentionally not actively pursued them while working on the Rootstock milestones. At the same time, I do not believe it would be appropriate to reject future funding opportunities if they can help improve SwaptoX as a protocol.
I do not view Rootstock simply as the project’s initial funder.
I view Rootstock as the ecosystem where SwaptoX becomes a production-ready protocol.
Many of the project’s most important milestones are being completed on Rootstock, including split routing, governance, security improvements, and the planned professional audit.
These are foundational improvements that define the protocol itself, and they will always be associated with the Rootstock ecosystem.
Although the earliest prototype was originally developed on Base, Base has remained only a development and testing environment. We have never treated Base as our primary launch ecosystem, nor have we invested in growing a user community there.
Rootstock is where SwaptoX is officially launching as a production protocol.
As the project grows, Rootstock will always be recognized as the ecosystem where SwaptoX established its first production deployment, first audited release, and first user community.
Rootstock also receives long-term product visibility.
For example, OpenOcean defaults to Ethereum when users first visit the application.
Similarly, when users first open SwaptoX, the default recommended network is Rootstock:
app.swaptox.com → app.swaptox.com/en/rootstock
This reflects our intention for Rootstock to remain the primary entry point for new users.
If SwaptoX later expands to additional ecosystems, I believe that expansion will also benefit Rootstock. Improvements funded by other ecosystems—whether new features, infrastructure enhancements, or developer tooling—will strengthen the protocol as a whole, while Rootstock continues to benefit from being the ecosystem where the protocol was first launched, validated, and established.
The long-term objective of SwaptoX is to become financially self-sustaining through protocol usage rather than grant funding.
Grants are intended to accelerate development during the early stage and reduce execution risk—not to become a permanent funding model.
Our planned business model is straightforward.
Initially, SwaptoX will continue providing fee-free swaps in order to build adoption and establish a user base. Once sufficient usage has been achieved, we plan to introduce a protocol fee of approximately 0.1%–0.2%.
Because SwaptoX is designed to operate with relatively low infrastructure and maintenance costs, we believe this level of protocol revenue will be sufficient to sustain ongoing development, server operations, maintenance, and future improvements.
My expectation is that approximately one year of user growth and ecosystem expansion will provide a strong foundation before enabling protocol fees.
Ultimately, my goal is for SwaptoX to operate as a sustainable protocol supported by its own usage and community, rather than relying on continued grant funding.
Hello everyone, @Tane @Curia @DAOstar_gov @ChronoTrigger @PGov @Axia @Kaf_Anode @krngill @SEEDGov @Eren_DAOplomats
Regarding the audit provider selection, I believe the primary consideration should not simply be the lowest possible cost.
The purpose of an audit is not only to obtain an audit report, but to identify and mitigate potential security risks before the protocol handles larger-scale user activity.
The reason we prioritized developing split routing early was also to support larger trade sizes and improve execution quality for advanced users. For this reason, choosing an audit provider with strong industry recognition is important, as security reputation can directly influence user confidence, especially for larger-value transactions.
After reviewing the quotations from multiple audit firms, I believe MixBytes is the most suitable audit partner for SwaptoX.
MixBytes has a strong reputation in Web3 security auditing and extensive experience with DeFi infrastructure.
Their relevant experience includes:
OKX Aggregation Router
1inch Aggregation Router V4
Liquidity protocol audits including:
Velodrome
SushiSwap
Curve
This experience is highly relevant because SwaptoX combines both aggregator logic and interactions with multiple liquidity protocols. A security team with direct experience in these areas is more likely to identify potential risks specific to routing, execution logic, and liquidity integrations.
In addition, MixBytes provides both:
an initial audit phase before deployment;
a post-deployment re-audit and deployment verification phase.
This ensures that the deployed production code is consistent with the audited code.
The original $12,000 MixBytes quotation covered only SwaptoXRouter.
However, compared with Hacken’s quotation of $14,600 for auditing both SwaptoXRouter and SwaptoXTimelock, the cost difference was relatively limited.
During the discussion, Hacken considered SwaptoXRouter and SwaptoXTimelock to be closely related from a security perspective. They recommended that SwaptoXTimelock should be included in the audit scope, and they were not able to provide an audit service if the Timelock contract was excluded.
This indicates that reviewing the Timelock contract is also an important part of the overall security assessment, especially because the Timelock mechanism will be deployed as part of the protocol’s governance and security architecture.
Therefore, I contacted MixBytes again and requested a revised proposal that includes SwaptoXTimelock.
MixBytes provided the following two options:
Scope:
SwaptoXRouter
SwaptoXTimelock
Audit Cost:
$15,000
Quotation:
Scope:
Audit Cost:
$10,000
Both options include deployment verification after the audit to ensure that the audited code matches the deployed production code.
Additionally, if audit findings require code changes and the modification scope remains within the agreed limit (less than 10% of the audited code), MixBytes will provide the re-review without additional charges.
Based on these options, I believe MixBytes provides the best balance between security expertise, relevant experience, audit coverage, and cost efficiency.
My preferred choice is Option 1, because it provides a more complete security review by including SwaptoXTimelock.
However, Option 2 is also technically acceptable if the Collective prefers to minimize the audit budget, because an issue within SwaptoXTimelock would not directly compromise user funds or swap execution security.
I welcome everyone’s feedback and recommendations.
@Ignas Sorry, I could only mention 10 reviewers due to the platform limit. Tagging you here separately so you can participate in the discussion above. Thank you.
Hello everyone,
@Tane @Curia @DAOstar_gov @ChronoTrigger @PGov @Axia @Kaf_Anode @krngill @SEEDGov @Eren_DAOplomats
I would like to provide a few updates and request guidance on the remaining items.
I have transferred the domain to Cloudflare and enabled the relevant services.
However, I have not observed a significant improvement in latency, or the improvement has been limited. Theoretically, Cloudflare should still provide a better access experience for users in different regions globally.
If there are no further concerns regarding the public comparison page, I plan to disable it after 5 days.
The reasons are:
The API continues to be updated, and maintaining the public comparison environment requires additional resources.
The current comparison page relies on a dedicated Rootstock RPC endpoint rather than a public RPC endpoint.
This RPC endpoint was provided after coordination with the Rootstock team because both public RPC endpoints and Alchemy currently do not support the required StateOverride functionality.
After the comparison testing phase is completed, this dedicated RPC endpoint should be removed as part of normal security and infrastructure management.
Regarding the audit plan, I would appreciate the Collective’s guidance if there are any further recommendations or required adjustments.
As previously discussed, completing the audit plan is a necessary condition for proceeding to Milestone 3.
Currently, the audit options and recommendations have been provided, including:
MixBytes SwaptoXRouter + SwaptoXTimelock audit: $15,000
MixBytes SwaptoXRouter-only audit: $10,000
If there are any concerns regarding the audit scope, budget, or milestone planning, please let me know so I can adjust the next steps accordingly.
Thank you for your time and feedback.
Thanks for the updates @SwaptoX. Several questions have been circulating in this thread for a while and you have asked for guidance more than once without a clear answer coming back. Rather than adding to that pile, I will try to converge where I can and be explicit about where a wider decision is still needed. I would inviter delegates to be mindful of adding new questions.
On the comparison page:
I would suggest keeping it live until M2 is recorded as closed.
The 55% commitment you made is written as something reviewers can verify at any time using that page, so retiring the page retires the commitment along with it. If the dedicated RPC endpoint is the cost driver, a reasonable middle ground is publishing the scenario list and the raw per route results together with a script others can run against their own endpoint. That preserves the check without keeping infrastructure open indefinitely, and it also closes out what @Tane asked for regarding publishing the scenario set and posting results rather than conclusions.
On audit scope:
Option 1 looks like the right call to me.
The $5k difference buys review of the contract holding admin rights and the fee cap, which is the mechanism the Collective has been asking to see verified since June. Hacken reached the same conclusion independently when they declined to audit the Router alone. One thing bears directly on the scope decision though. If the Router’s executor pointer can be changed without passing through the Timelock, then leaving SwaptoXEntered out means the swap path stays replaceable at will and the Router as security boundary argument weakens. If that change is timelock gated, the narrower scope holds up well.
On audit funding:
I looked at the Grant Guidelines thread for directions on this.
@tamlerner addressed this in early July, noting there is no separate audit fund for now and that the leaning is direct to auditor payment tied to audit readiness rather than an initial tranche. Applied here that points toward the Collective paying MixBytes directly once contracts are frozen, rather than a cash tranche to the project. That said, I am not in a position to commit the Collective to it on my own, so I will open a separate discussion on audit funding so we settle the general rule instead of resolving it case by case and leaving you blocked in the meantime.
On what starts M3:
I think a code freeze is the piece still missing. If audit readiness is the trigger for funding, then readiness has to mean something concrete, and right now the contracts are still moving. Your own notes say the Timelock may change, the fee cap moved from 0.3% to 0.2%, and the Router sits close to the 24KB limit. MixBytes only covers re-review at no cost under a 10% code change, so sending contracts to audit before they are frozen risks paying for the same work twice. I would suggest M3 opens on a frozen contract set for the audit, together with the consolidated scope document you already committed to publishing with the deferred M2 items clearly marked. Worth also recording Cloudflare as delivered with no measurable latency gain so that item does not stay ambiguous.
I will get the audit funding discussion started this week.
Coming back on the quotes after a more careful look @SwaptoX:
The spread is wide, from $2,275 with Omniscia to $24,000 with OpenZeppelin for the same 407 LOC Router, with Guardian at $3,500 including a $100k public bug bounty, FailSafe at $5,760 and Halborn at $7,000 sitting in between. MixBytes at $12,000 for the Router alone was already in the middle of that range before scope expanded to $15,000, and that is worth weighing against the $9,000 still to be disbursed across M3 and M4.
I still think Router plus Timelock is the right scope, so I would not narrow it, but the mid-tier firms were only ever asked to price the Router on its own. Going back to Halborn and FailSafe with the full scope, and asking whether deployment verification is included, would give a better comparison.
Funding remains a pending discussion on our side and I will open it, but looking at the total grant for this project at $18.000 and still $9.000 left for M3/M4, it would certainly benefit reducing the audit from $15.000 to ~$3.000 to $7.000 maybe with a bug bounty program included.
I had suggested the $15.000 choice in my previous post, but on a more carefull look I think it’s worth broadening the expectation towards the other cheaper options.
Hi! Whenever something comes along that makes swaps easier, it has my full support.
I took a look at the listed tokens, and I think the selection is very solid for the Rootstock ecosystem. All the major tokens are there.
I simulated a few swaps, and the routing seems to work correctly. However, I do have a couple of suggestions. For RBTC/DOC and RBTC/BPRO swaps, it would be great if the router used the Money On Chain dApp directly instead of routing through Sovryn. The same idea could apply to RIF/USDRIF swaps, which could be executed directly through RIF On Chain.
I also noticed there are no cross-chain swaps. I understand that’s not the core focus of the dApp, but since Boltz was recently paused, there’s now a gap in the ecosystem. Boltz provided an easy way to move funds into and out of Rootstock using both on-chain Bitcoin and the Lightning Network. If you could add that functionality, I think it would become a very important use case.
There is currently a real need in this area, and I believe the first protocol to integrate it will attract a significant number of users, as well as strong support and recommendations from the Rootstock community. It would be especially valuable for smaller transactions, where using the PowPeg isn’t practical because of its minimum amount requirement.
Thanks for your detailed feedback, @ChronoTrigger .
Keeping the public comparison page available until Milestone 2 is officially marked as completed is completely fine.
I will keep it online until M2 is closed, and then retire the public comparison page as planned.
If audit funding is approved, I strongly support Rootstock paying the audit provider directly.
This approach would not only reduce operational risk, but also help Rootstock establish a direct relationship with security firms and potentially build longer-term cooperation with them.
The audit preparation can proceed once the final audit scope and contract version are confirmed.
The governance upgrade, the multi-admin Timelock verification, and the 2028 fee lock verification will be moved to Milestone 3.
The main reason is that the audited contract version should represent the final frozen version. If these items are verified during M2 and the audit later requires contract changes, the same verification work would need to be repeated during M3.
The possible contract adjustments and the fee cap change from 0.3% to 0.2% are secondary reasons. This does not mean the contracts are incomplete; rather, I believe the final verification should be performed against the audited and finalized deployment version.
Regarding the audit provider selection, I recommended MixBytes because they have strong experience with both aggregation routers and liquidity protocols.
Their experience with similar systems may increase the chance of identifying potential risks specific to SwaptoX’s architecture.
My view is that an audit should primarily be about improving security, not simply obtaining an audit report.
However, I fully respect the Collective’s feedback and will follow the final decision after discussion.
Regarding the suggestion from @manuvegadt about using Money On Chain liquidity for DOC/BPRO pairs, I researched this further and confirmed that there are indeed specific liquidity pools such as RBTC/DOC.
Money On Chain is not a general-purpose liquidity platform, but it provides specialized liquidity for specific assets. Because of this specialization, the available liquidity can be meaningful, and I agree that integration could provide value.
However, I believe this integration should be considered after Milestone 3. At the current stage, expanding the scope further would introduce unnecessary complexity before completing the existing milestones.
Regarding SwaptoXEntered, the reason it is designed as a replaceable execution contract is the same: as new liquidity protocols are integrated, the execution layer may need to be updated.
However, the replacement process is not permissionless or immediately changeable. Updating SwaptoXEntered requires the Timelock process, including the required administrator approvals and delay period.
Therefore, the Router security boundary remains protected by the Timelock-controlled upgrade mechanism.
@manuvegadt also mentioned that Bitcoin ↔ Rootstock cross-chain functionality could attract users. I agree that this could become a valuable use case for the Rootstock ecosystem.
However, cross-chain functionality requires significant liquidity and infrastructure support, so it is not something we can immediately prioritize at the current stage. We will keep this as an important future direction for SwaptoX.
I really appreciate your comment. I’m glad to hear that integrating swaps directly from Money on Chain could be on your roadmap. Whenever you decide to move forward with it, please don’t hesitate to reach out to me, and I’ll be happy to connect you with the technical team.
Thank you very much for your support and for offering to help with the integration.
If there is technical support available, integrating Money On Chain liquidity would become much easier. For example, if you could provide information about the contract interfaces, quoting method, swap execution method, and whether there is any flash loan support, I would be able to evaluate and integrate it much more efficiently when the timing is right.
I may not start the integration immediately, as the current priority is completing the existing milestones, but understanding these technical details in advance would allow me to spend much less time when we decide to proceed.
May I ask if you are part of the Money On Chain team or ecosystem? If so, what would be the best way to contact you when we start evaluating the integration?
Thank you again for your support.
@Tane @Curia @DAOstar_gov @ChronoTrigger @PGov @Axia @Kaf_Anode @krngill @SEEDGov @Eren_DAOplomats
Hi everyone,
It has been over one month since the official M2 delivery (July 5).
I would like to ask for guidance on the next steps so we can continue moving the project forward.
Regarding M2, after more than 20 days of discussion and clarification, I have not seen any additional concerns or objections regarding the delivered scope.
For the audit discussion, I understand that funding and scope decisions may require additional coordination. If the Collective needs more time to finalize the audit support decision, would it be possible to proceed with M3 while keeping the audit process moving in parallel?
This would help avoid unnecessary delays while ensuring the audit requirements are still properly addressed before the next major deployment stage.
Thank you for your guidance and support.
Thanks @SwaptoX. Good to have the comparison page staying up until M2 is closed, and the confirmation that replacing SwaptoXEntered runs through the Timelock with admin approvals and a delay answers what I was probing on scope. Direct payment to the auditor also seems to be where everyone lands, and your point about Rootstock building a direct relationship with security firms is a fair argument for it.
I have started the audit funding discussion internally and will bring something back as soon as there is a position to share.
On starting M3 in parallel, I think most of it can move now. The React frontend, the SDK and widget, the docs and the API work do not touch the contracts under audit, so there is no reason for those to wait. What I would hold is the Timelock and multisig deployment, since those are the items that moved out of M2 specifically to be validated against the final audited version, and deploying them ahead of the audit puts us back in the situation where the same verification gets done twice. If you publish the consolidated M3 scope with the deferred items marked, splitting it that way should let you keep building while the funding side gets settled.
Thanks @ChronoTrigger for providing guidance on the M3 progression and audit discussion.
Regarding SwaptoXTimelock:
SwaptoXTimelock is the only administrative execution layer for SwaptoXRouter.
In simple terms, all administrative operations must go through SwaptoXTimelock, including updating SwaptoXEntered and modifying protocol fees.
All SwaptoXTimelock operations follow a two-step governance process:
one administrator submits a request, the operation enters a 72-hour public delay period, and a second administrator must confirm the execution before it becomes effective.
The 2028 zero protocol fee lock and the implementation of the 72-hour timelock mechanism for all administrative functions will be verified against the final audited deployment version during M3.
Regarding M3 scope:
M3 funding request: 4,000 USDRIF
Estimated duration: 45 days
Based on the discussion, I will update the M3 scope and publish the corresponding on-chain proposal as soon as possible.
Updated scope:
Frontend migration to React / Next.js framework with the Rootstock routing page:
app.swaptox.com/[locale]/[chain]
app.swaptox.com/en/rootstock
app.swaptox.com → auto redirect → app.swaptox.com/en/rootstock
Build a mobile-optimized interface using the swaptox-widget component (formerly Mini SDK): mini.swaptox.com
M2 deferred UI-related items:
The originally defined M3 scope:
Hello everyone!
I see a very mature discussion here. I stopped by to take a look at the application, and you can really see the work that has gone into it. The community has been actively listened to, and decisions are being made based on the needs of the ecosystem.
I understand that you are a solo developer, and I have actively read the perspectives of other readers regarding this. I have a question in that regard: Have you done any networking within the ecosystem in an active search for builders who could help you accelerate the development process? There are multiple initiatives, campaigns, and events in the ecosystem that you can participate in, either in person or online, to talk about your vision and share it with other entrepreneurs and developers.
Regarding the application, I have tried it, and it is rewarding to see how well it works. I like the wide range of tokens that can be viewed, and I like that it is focused on the Base network. The type of user on Base is different from the type you find on Rootstock, and it would be interesting for the ecosystem to attract interest from this audience.
I know that, at the stage the project is currently in, the following suggestion may be a very low priority; however, users translate into utility, and I believe this will be useful to you as well as to the ecosystem in general.
You have a referral section, which is fine in principle, but if you want the word to spread quickly and with impact, you should offer a meaningful incentive. I suggest reviewing the feasibility of a cumulative points system based on product usage. This is something that has worked very well, and so far Oku Trade continues to implement it, even with physical rewards (HODDIES).