Security

First Principles

As the DEFI space continues to mature, security is foundational to its success as a mechanism for promoting trust and transparency. Therefore, we have built avtoMATIC with a security-first approach, designing with the investor's experience in mind, and employing industry best practices and secure coding and development practices for optimal runway for protocol stability.

We believe that robust security builds trust with a community of users and investors, and demonstrates a long-term viable solution in the DEFI space, resulting in a higher protocol TVL.

Understanding the Attack Surface

Many DEFI participants consider security only in terms of contract security. We add traditional cybersecurity attack vectors to this consideration. Our approach addresses both security arenas in the prevention of exploits, hacks, and attacks by bad actors.

Considerations we have built into our security stack for protocol design and team management include:

• Infrastructure security design

• Secure development practices

• Back-and-front-end attack vector analysis and prevention

• Implementation of rule of least privilege across the accounts that touch our infrastructure and development environments

• Multi-factor authentication for remote authentication

• Stringent organizational password policies

• Other mechanisms that enforce hardening techniques on the servers and solution stack that represent our baseline

Finally, the avtoMATIC team uses multi-signature wallets to prevent potential insider threats from executing unauthorized transfers of funds.

Secure Coding & Development Practices

We have integrated security testing into our testing processes with a dual-prong testing and optimization approach. It aids in defending against current attacks in cybersecurity and preventing future attacks, including those that reveal unknown security flaws in our code base.

First, we implement gray box fuzzing into our ecosystem of security testing. Our team researches common attacks across the Polygon and DEFI ecosystem and builds code to mitigate them. Second, our team uses a red-team method to emulate well-known attacks against our code base, or "N-Day attacks", allowing us to both practice responding to security threats and put our system under stress in a testing environment.

Combining gray box fuzzing and the red-team method with static and dynamic code analysis techniques will aid us in circumventing 0-Days, or unknown security flaws in our code base.

Further, we employ manual testing with each release of the software baseline. The release of software follows a development cycle that applies unit tests, regression testing, security tests, and then finally manual auditing/testing measures that ensure a level of "user acceptance" before software is released for our production site. While this may slow down the pace at which we could release software, we believe it is imperative proper testing measures are in place to promote a safe and secure avtoMATIC ecosystem.

The development team spent two weeks of in-depth testing following the v1 release of avtoMATIC. Our team follows a standard agile development process, operating in two-week sprints. This includes two scrum of scrum like sessions per week between stakeholders and the development team. Topics around testing and quality assurance (which includes security) are core topics as part of these discussions.

Software Development & Licensing

The development team for avtoMATIC have been writing production-level software for years. Our hope is the maturity and level of professionalism by the team is demonstrated in the usability of the platform. Both front-end, back-end, and the smart security teams are DEFI natives and have been involved in the development of other projects on chains like Stellar, CHIA, and others. The development team was selected based upon its experience in the crypto domain and level of maturity.

Like any good development project, some aspects of our code base make use of public libraries to take advantage of existing mature solutions. For example, we make use of Open Zeppelin contracts in our code base (where relevant).

However, other aspects of our code base dealing with the proprietary aspects of the Foundry we consider to be proprietary and represent critical code that should be protected. We want to protect avtoMATIC investors and the funds held within the project, especially as avtoMATIC is entirely innovative and provides vast advancements in the DEFI space.

Business 1.1 Commercial Use License

We protect the proprietary aspects of the research and development expenditures and outputs of the project while allowing the broader community to benefit from our efforts. Therefore, we will be choiceful in how we release our code, as we will protect the investments represented in the development of the platform and future innovation.

We plan to release the code in a progressive disclosure approach under the Uniswap V3 Business 1.1 Commercial Use License. Staggering our releases will will serve as a forcing function on the project to continue to innovate and promote TVL. It balances the three aims of giving back to the community, protecting the results of research and development, and delivering innovation.

MIT License

For those components of the code base, such as vaults contracts, that make use of public libraries, we will follow a traditional open-source approach under a MIT License. These will be made public and be published for review and verified on Polygonscan.