Introduction
Hello everyone, I’m known as CakeMaker in the Sonic community, and I’m a part of the core development team. Over the past few weeks, we have been working closely with the Dfinity team to launch our SNS proposal. Our community is already aware of this, and I’m thrilled to share more details about our proposal and whitepaper through this forum post.
This post is a forum for the IC community to discuss the Sonic SNS and ask the founding dev team any questions.
Sonic is a DeFI/AMM protocol on the Internet Computer, leveraging the IC’s unlimited scalability to provide a collection of DeFI products, including swaps, liquidity, and more.
What’s next?
Once the development team receives adequate feedback and comments, a proposal will be launched to enable principal tu57s-7iaaa-aaaal-achra-cai in SNS-W for the initiation of an SNS generation on Sonic DEX.
Hey Buddy! Great to see things moving forward with Sonic. I’m a big fan. I’ve read the whitepaper which is very detailed and no doubting the experience of the dev team. Playing devils advocate I’ve got a couple of questions…
Is the SNS launch too early in your roadmap? Should the product be built out more and then launched via SNS?
Does SNS launch potentially slow down the development process due to the voting process of deploying each update? (Kinda linked to Q1)
I know there will be some questions over the regulatory environment of synthetic assets… is early SNS launch a mitigation of this? (I appreciate that you might not want to go ‘on the record’ on this topic. Its potentially a tricky one but I know people might be thinking it)
I know you guys are looking at metamask integration. Are you working with Funded to keep Plug wallet development up to speed with any Sonic changes? How about other ICP wallets? (I imagine using ICRC standards help here)
Any plans to re-launch WICP on ICRC standards?
Whatever happens I’ll be rooting for you guys! We need great teams like you on the IC!
The decision to implement SNS for Sonic was made following careful planning of our roadmap and vision board. In order to achieve our goals, we require funding to expand our team and ensure legal and compliance measures are in place. Currently, Sonic lacks an audit and compliance framework, which poses a risk not only for our platform but for every DEX in light of ongoing SEC regulatory issues. Adherence to regulations is critical for scaling, and it is imperative that we follow these guidelines for long-term success.
While the SNS launch introduces a governance mechanism that allows the community to vote on updates and proposals, we have considered measures to ensure the development process remains agile and efficient. The SNS voting process is already designed to be transparent and streamlined, and we are committed to balancing community input with the need for timely development and innovation.
As an organization, we take regulatory compliance very seriously and are actively monitoring developments in the regulatory environment for synthetic assets. While SNS may provide some level of decentralization, it is not intended as a specific mitigation strategy for regulatory concerns. We will continue to work with legal counsel and regulatory authorities to ensure compliance with applicable laws and regulations.
We are actively working to ensure compatibility and integration with a variety of wallets, including MetaMask, Plug Wallet, and other ICP wallets. Our goal is to provide users with flexibility and choice in how they interact with the platform. However, we are not involved in any development process of Plug.
Our goal is to ensure that as much of the system as possible is under the cryptographic control of the SNS to enable community governance and decision-making. However, there may be certain components or aspects of the platform that require off-chain for practical or technical reasons. These components could include, for example, third-party integrations or certain user interface elements. We recognize the importance of minimizing reliance on centralized infrastructure, and we will continuously work to enhance the decentralization and security of the platform.
We are also committed to being transparent with our community about the architecture of the platform and any components that may involve off-chain elements.
As we continue to develop and improve the Sonic platform, we will actively explore opportunities to further decentralize these components and increase the level of cryptographic control exercised by the SNS.
Just following up on @levi’s question: Is there an architecture description of Sonic? As in: which canisters is Sonic comprised of, and which exact parts of the architecture are on-chain vs. off-chain? For instance, a simple lookup of Sonic’s main URL indicates that the app front end is served from AWS, which may mean it’s not under the control of the SNS.
We have mainly Swap, Liquidity and Assets APIs and all of them routed through single canister 3xwpq-ziaaa-aaaah-qcn4a-cai. The high level and technical level components details are covered here.
We evaluated different options for hosting frontend, one of our major concern is most of the icp domains being blacklisted by major ISPs. We are currently evaluating custom domain mapping support and looking at new boundary node updates. The updated FE canister will be added to SNS DAO later via proposal
How many canisters are there in total? Why can’t the FE be added before SNS? I agree that blacklisted domains create a huge issue, however I think this problem prob needs to be solved at the network level. Also will the code be open source after listing on SNS? Otherwise how can the community audit the code?
The Sonic front end canisters are already developed, but they are not yet live due to the reasons mentioned earlier. Once the issues are resolved, we can move our front end from AWS and go live with canisters. https://eukbz-7iaaa-aaaah-ac5tq-cai.icp0.io
What does “routed through a single canister” mean?
Is it just that the canister saves the request and then an off-chain service polls the canister for the requests and processes the transactions in the off-chain service?
What does “routed through a single canister” mean?
We do have inter canister calls to token canisters, but currently we don’t have any off-chain service polls or anything similar.
All of the transaction processing, requests processing etc. happens within the mentioned swap canister.
I think a high-level architectural overview of your setup is needed for this thread. It’s not clear how much of Sonic is on-chain and off-chain. Also I think it’s important that your project is open-source before the sale, from what I can see you plan to open-source after. Would you reconsider this decision?
The only off-chain component that Sonic relies on is the graphql api server for analytics. The purpose of this api server is to act as ETL component that process and organize raw data retrieved from the canister, which is then presented in the analytics section of sonic. Unfortunately, we have not yet identified a suitable alternative for implementing this feature within the canister.
As you have correctly pointed out, our initial plan was to open-source after the sale. However, after taking into consideration the feedback from the Dfinity team & community, we have decided to prioritize this and open-source our project before SNS. We believe that open sourcing-before the sale is crucial for establishing trust and building a strong foundation for our project.
Thank you again for your valuable input, and we look forward to making this happen within few days.
This is fantastic @Bugslayer! Thank you for your quick turn around on the feedback. I’m glad that you can see the value of establishing trust with the community through transparency.
Just to clarify something that was said earlier:
We have mainly Swap, Liquidity and Assets APIs and all of them routed through single canister 3xwpq-ziaaa-aaaah-qcn4a-cai . The high level and technical level components details are covered here.
If I understand correctly now, you have multiple canisters, one for each of these APIs, but they are all proxied by a single canister? Or they all exist on the same canister?
For further clarity, I am adding below info for the community to review -
Sonic component level details
All types of Sonic V1 transactions are handled by the swap canister (3xwpq-ziaaa-aaaah-qcn4a-cai). The canister has three main logical components.
Swap Router
Swaps are the action of trading one asset for another with an opposing party, oftentimes overseen by a trusted third party. With Swap Router, users can deposit a token and receive their desired token automatically in a trustless fashion. A full swap through the Sonic Swap API has four update calls documented here. Swap Example - Sonic
Liquidity Pool
A liquidity pool holds a balance of the two tokens that make up the top-level swap pair. Users who want to make a swap are actually trading with the underlying liquidity pool. Liquidity pools price their assets based on the ratio of the underlying assets. Users who want to make a swap are actually trading with the underlying liquidity pool. Liquidity pools price their assets based on the ratio of the underlying assets. The component exposes two major apis addLiquidityaddLiquidity and removeLiquidityremoveLiquidity, the transaction flow of these apis are documented here. Liquidity Example - Sonic
Asset Wallet
This component gives users a way to hold their assets within the canister so that they can process any LP or Swap related transaction much faster. The Asset wallet api currently follows a standard derived from DIP20, an example flow of using this api is documented here Assets API - Sonic
Decentralisation & Voting power
Sonic will be decentralised with all our codes are deployed in canisters, the canister details are shown below
Currently, the only off-chain component that Sonic relies on is the analytics API ( https://api.sonic.ooo/ ). Unfortunately, we have not yet identified a suitable alternative for implementing this feature within the canister.
To ensure a meticulous and extensive evaluation, we will be engaging multiple auditing agencies. Our audit milestone is already outlined in our roadmap, and we plan to conduct the audit post SNS.