I hope @memecake has addressed most of your concerns, but I would like to add some technical aspects here (because I believe you are also a developer). We appreciate the efforts of the previous team, but their solution was never optimized to scale with more token pairs. Previously, it was using a brute-force
or linear search
approach for token swap routing, which slowed down the performance of both the frontend and backend. We have iterated over the code to optimize it further in production, and we are actively monitoring the performance of these changes in our production app (FE). The stable version of these changes will be merged into future updates of the sonic-js client library.
Thankyou for the reply.
Hi @bjoernek
Thank you for raising the important topic of security reviews and best practices. At Sonic we recognize that security audits are essential for identifying and mitigating potential vulnerabilities, and they play a crucial role in ensuring the robustness and integrity of our platform. We have planned for thorough security audits to be conducted by reputable third-party security firms with expertise in blockchain and decentralized finance (DeFi) security. These audits will encompass a detailed examination of our smart contracts, protocols, and overall system architecture.
Security audits are an indispensable component of our development roadmap, as they are integral to achieving success in the decentralized finance (DeFi) landscape.
(Link - Future of Sonic - Roadmap - Sonic Whitepaper)
Currently, our team is conducting unit testing, end-to-end testing, and long-running test scenarios to ensure code correctness and security. The team avoids including test and development code in production. We take measures to ensure that production code is free from security risks associated with test and development setups.
We avoid using forked repositories that lack maintenance and use widely adopted, well-reviewed components. Component versions are pinned to prevent automatic updates to potentially compromised versions. We avoid implementing cryptographic algorithms ourselves and adhere to standards set by organizations such as NIST and IETF.
We appreciate the trust that our users place in us, and we will continue to prioritize security as we develop and expand our platform.
Let’s check the distribution of tokens as well as technology.
Only a small amount of 1% Airdrop (liquidity provision, testnet, Airdrop to Memecake) is allocated, and many enter the team’s treasure.
Let’s read it together
Great thread.
The distribution process has been designed with utmost transparency. With a total supply of 125 million tokens, an initial 1% airdrop demonstrates our commitment to a fair and inclusive allocation. If deemed necessary, we will consider conducting further airdrops after the SNS launch, subject to approval through a DAO vote.
The team has also been allocated a portion of the tokens, which serves a crucial purpose in the project’s development. This allocation is intended to facilitate the hiring of new team members, ensuring that we continue to attract top talent. Moreover, these tokens enable us to maintain a dedicated focus on the product’s success, driving innovation and growth in the long term.
I think the security audits need to be completed before the SNS.
There should be non SNS options (like CigDAO) for folks who want to just tokenize with low barriers.
But to SNS we need to keep the bar high. So yeah, security audits prior to SNS, esp. for defi.
Appreciate your feedback. We have already explained above how we are tackling this issue currently.
As some of you may be aware, our team is currently in the process of making significant architectural changes to Sonic. These changes are aimed at enhancing the platform’s capabilities, scalability, and overall user experience.
Given the extent of these architectural changes, it would not be efficient or practical to conduct a security audit at this stage. An audit conducted now would be based on the current structures, which are set to be replaced in the near future.
For this reason, we have made the strategic decision to postpone the security audit until the new architecture is finalized. We believe that conducting the audit in tandem with the completion of the architectural changes will provide the most valuable and relevant insights into the platform’s security.
We thank our community for their understanding and patience as we work diligently to build a platform that meets the highest standards of security, performance, and usability.
I just read through Sonic - Towards a Universal Standard for Decentralized Cryptocurrency Trading - Sonic Whitepaper, this is very helpful!
I have a question about the initial token allocation. Some things are pretty clear to me
- team gets 14.5%
- psychedelic gets 4% for acquisition
- seed investors get 2%
- 22% is sold in the decentralization sale
Now there are left
- trading rewards 25%
- LP rewards 7.5%
- treasury (contributor grants, LP, programs) 16%
- airdrop 1%
- future funding 8%
Who will own those? Is this all going into the treasury controlled by the Sonic SNS? Does that essentially mean that the Sonic SNS will have a treasury of 25% + 7.5% + 16% + 1% + 8% = 57.5% of the supply, and that the further breakdown is mainly to show how you intend for those tokens to be used?
The setting up is showing signs of great promise
You’re right.
A significant portion, precisely 57.5%, of the remaining tokens is allocated to the Treasury.
I shared my thoughts in this Nuance article. Please don’t be disheartened by critique. The majority of us want to see Sonic do well. I honestly think you will get there, just maybe not this year.
[https://] nuance.xyz/2vxsx-fae/3241/sonic-is-great-but-its-not-an-sns-candidate-yet
Thank you for the feedback.
We would like to clarify DFINITY’s reasoning for abstaining on the SNS-W proposal for Sonic.
Before delving into the details, we would like to reiterate the disclaimer mentioned in our voting standards: The SNS framework is a relatively new concept, and both the community and we possess limited experience in reviewing and voting on actual proposals. As we gather more experience over time, our perspectives and focal points may evolve.
Let’s now discuss our actual reasoning. Taking into account our published voting standards for SNS launch proposals, we would like to emphasize that the Sonic team has adhered to nearly all criteria, including forum syndication, white paper, open sourcing, and more. We view this as highly positive.
However, we could not fully follow the explanations regarding security reviews. As outlined in the published voting standards, the need for a security review depends on the nature of the decentralized application (dapp). For dapps where exploits could result in significant financial consequences, the industry standard demands a high level of scrutiny. Decentralized exchanges (DEXs), such as Sonic, fall into this category. Conversely, for dapps with a lower financial focus, a less stringent standard may be applicable.
Given that a security review is vital information for assessing the security and thus the maturity of a DEX, it would be logical to conduct a security review before launching an SNS. However, the Sonic team intends to perform a security review only after the SNS launch.
In conclusion, while the Sonic team’s adherence to most criteria is commendable, the lack of a pre-launch security review raises concerns about the DEX’s security.
The community supported the SNS-W proposal for Sonic. Since we generally prefer not to go against the community’s direction, as stated in our voting standards, we chose to abstain.
So far, there have been a lot of rejections, and I’m relieved that the community has made the right decision.DEX with only 1% assignment to the community is the same as CEX.
Wait, what? Did you guys tell tell weeks ago you had reservations about the lack of audits? Why wait until the last minute? You know how much weight Dfinity votes holds and should definitely voiced this concern prior now.
I have 0 stake in Sonic but I am worried y’all may be pushing builders out of the ecosystem with these mind-blowing decisions. I am definitely feeling less enthusiastic about $ICP than I was yesterday.
They choose to abstain how is that bad?
These concerns have indeed been raised before:
- The voting standards, encompassing remarks on security audits, were published on April 21st.
- On May 3rd, specific concerns were raised about security audits and open sourcing the code for Sonic.
- Furthermore, other community members in this forum thread expressed concerns regarding the absence of security audits before launch, which are especially crucial for a DEX.
How much is it to get a security audit. Maybe this is why we need smaller rounds of funding for many of the other DEX’s going online as well.
This is a valid point. Security audits are not inexpensive. While I’m not an expert on the subject, I’ve seen quotes of at least 20k or more. As a community, we should contemplate how to help DEXs overcome this challenge.
I’ve heard that other projects are considering bug bounties. This approach might be sufficient initially for dapps with a lesser financial focus.
I think you should give up SNS in case of a failure due to a funding problem.I look forward to your hard-working vote.
Community allocation is one percent, team treasure is 99 percent
Reference