Risk Toolkit

‍Introduction

Aztec Network (“Aztec”) will be a privacy-preserving Layer 2 on Ethereum. It will boast a powerful, completely programmable, and unique execution environment with features like private and public state, private and public transaction execution, and account abstraction. 

Aztec intends to provide developers with full control and flexibility to develop and deploy decentralized applications while retaining privacy for users to benefit from encryption with faster and cheaper transactions secured by Ethereum. This is made possible by Aztec’s unique portal contract architecture and viewing keys. Developers building on Aztec need to ensure that their applications comply with all applicable laws. To help developers build successfully, starting from testnet, the Aztec Foundation prepared this Risk Management Toolkit (“Toolkit”) so that potential issues can be spotted and addressed during the application development process.

Disclaimer: This document is intended for informational purposes only to assist developers in gaining a general understanding of certain legal and regulatory regimes to consider for risk mitigation purposes when using Aztec tooling. Risk mitigation efforts depend on the particular facts and circumstances of tools built on Aztec and on the extent to which regulator understanding and interpretation of blockchain technology continues to evolve. No specific risk mitigation effort or combination of mitigation described herein is assured to address any particular regulator’s concern. Nothing in this document should be construed as legal advice or an opinion with respect thereto. While building on Aztec, you must make your own assessment of the facts rather than relying on the Toolkit for your risk management determination. You should consult your own attorney and, with counsel, conduct your own assessment of the facts and relevant authorities rather than relying on this document for your own risk management determinations or for any other purpose. The Aztec Foundation has no obligation to update this document or notify you of any changes in law, or if any matters come to our attention that might affect the continuing validity of any statements contained in this document.

‍

Why have a Risk Management Toolkit?

Aztec is built to be used by a wide-variety of stakeholders, who naturally have diverging expectations and needs. This Toolkit is intended to serve as a resource for these stakeholders, particularly developers, to build privacy-first applications, while maintaining best practices to mitigate risk.

‍

What do we mean by “risk management”?

The Toolkit is not meant to be a guide for regulatory risk management. Instead, we outline considerations for effective risk management when building on Aztec. By design, zk-SNARKs abstract the interaction between a prover and a verifier such that the prover can validate a statement without revealing any information about it. This ensures a great amount of privacy among its users, not otherwise demonstrated in other decentralized protocols. Developers have a considerable amount of discretion when building; they may choose to incorporate Aztec upgrades in their own applications, have access to viewing keys, and may choose to incorporate other privacy measures. 

Building on Aztec does not create a legally binding relationship between developers, and Aztec, the Aztec Foundation and/or Aztec Labs, but it is important to be mindful of the legal and regulatory obligations that may apply to your project to ensure the development of a safe, diverse and sustainable ecosystem. 

‍

What are my responsibilities when building on Aztec? 

As an open-source developer building on Aztec, there is no contractual relationship between you, the developer, and Aztec, the protocol, nor Aztec Labs and/or the Aztec Foundation (the “Aztec Parties”). Each of the Aztec Parties is not a representative of, does not speak on behalf of, and has no authority or control to bind the broader stakeholder community, which is comprised of independent contributors.

To build on Aztec, you may use Noir, an open-source programming language that intends to allow for the seamless construction of privacy preserving Zero-Knowledge Proofs (“ZKP”) cryptography circuits. Your use of Noir is “as is” and “as available.” When building on Aztec using Noir, regularly check Noir Debugger and be cognizant of the Debugger Known Limitations as well as check to ensure you are using the latest version of Noir. If you discover a vulnerability with Noir, or other aspects of the Aztec network, that may expose Aztec to a technical vulnerability, or affect Aztec’s reputation, we ask that you escalate any vulnerabilities through Aztec’s Bug Bounty program as soon as practicable.

‍

What standard legal disclosures should I consider?

Every company and project is different, but you may want to assess the need for:

• Terms of Service (consider: what does your product do, who are your users, and what type of relationship do you have/want with them, if any?)

• Privacy Policy (consider: where are your users, what privacy/data protection laws apply, and what personal data do you collect/why do you collect it?)

• Trademark/IP Policy (consider: what are your brand assets, and do you need to protect them?)

• Cookie Policy (consider: do you use cookies, where are your users, and what laws apply to your cookie usage?)

• Risk Management Policy (consider: where are your users geographically, is your project accessible in sanctioned jurisdictions and/or to sanctioned individuals or entities–if so, how can you limit access, does your project require regulated screening of its users and subsequent reporting of suspicious activity and transactions? Generally, how do you identify, evaluate, assess, prioritize, and manage risk?)

This is not an exhaustive list of potential policies or considerations. You should consult your legal counsel early on to determine what is necessary and appropriate for your project. 

‍

What are sanctions and do I need to consider them?

Sanctions are the regulatory restrictions applicable to certain countries/territories, governments, groups, entities, individuals, sectors, types of transactions, or controlled goods or services. The nature and extent of these restrictions may vary (i.e. limitations on import/export, controls on specific goods and services, restrictions on financial operations, etc.), and it is important that all developers are mindful of these restrictions, including which are applicable in each developer’s respective jurisdictions. 

Violations of sanctions laws may lead to severe civil and/or criminal penalties against companies and individuals, including significant monetary fines, imprisonment, extradition, blacklisting, and disqualification of directors.

In addition, violations of sanctions laws can lead to damaging practical consequences, including harm to reputation and commercial relationships, restrictions in the way business is conducted, and extensive time and cost in conducting internal investigations and/or defending against government investigations and enforcement actions, even if ultimately exonerated.

Sanctions laws may apply to anyone engaged in business, and you should consult your legal counsel about how you should address them for your specific product and based on applicable sanctions laws in your jurisdictions.

What are some of the relevant use cases that could be built on Aztec? Are there specific legal considerations that I should have in mind?

Aztec is capable of supporting a vast number of potential applications and projects through its public and private transaction capabilities. Every project is different, and there are a lot of legal/regulatory areas to consider when building an application. We provide some sample use cases below and note some areas worth considering, but you should consult your legal counsel early on to identify what jurisdictions may have authority over your project and what the specific requirements may be applicable.

• Private Identity: Secure and privacy-preserving identity management. Applications could enable users to prove their identity or specific attributes (e.g., age, citizenship, or credit score) without revealing the actual data (passport/ID), minimizing the risk of identity theft or unauthorized access to personal information. There are a lot of areas to consider when working with personal data and attributes from global data protection/privacy laws to the Fair Credit Reporting Act. Consider whether you are using tools that are collecting analytics for marketing or other reasons that may also contain private information or may be governed by applicable data protection/privacy laws (e.g., Google Analytics).

• Private KYC. Without learning much about the user, you could verify their identity and use it for credit checks or other financial transactions like token transfers only amongst those who can generate valid KYC proofs. There are a lot of areas to consider when working with personal data and attributes from global data protection/privacy laws to the Fair Credit Reporting Act as well as global financial laws and regulations related to money transmission and money services businesses, if your application is involved in the transaction itself.

• Private Voting: Private, on-chain democratic voting (currently any voting on blockchains is public, allowing anyone to see who voted for which proposal). Like Private Identity and Private KYC solutions, you should consider whether you interact with personal information. You may also need to consider your risks in case of inaccurate reported outcomes or other failures of the voting system.
  
  
• Private Transactions: Private on-chain financial instruments/transactions (e.g., payments, regulated loan origination, bonds, contracts). Businesses will be able to transact confidentially, on-chain, without revealing sensitive trade secrets, pricing data, and other sensitive information, without intermediaries. Financial products and transactions may be heavily regulated, varying significantly based on your jurisdictional exposure. Some examples of topics you may want to consider: SEC/CFTC regulations, anti-money laundering laws and regulations (e.g., Bank Secrecy Act), banking laws and regulations, and MiCA. Depending on your application and whether you custody user tokens or funds, you may need to consider thresholds for deposits/withdrawals for risk mitigation. You should consult legal counsel to understand the scope of applicable laws as well as risk mitigations you may need to implement in advance of launch.

• KYC Token: Create a token that can only be held by users who have a valid KYC proof. KYC can be done through a third party and will assign a non-transferable proof to the user, who will then be able to buy or transfer the token. For example, this may bge used for payments for merchants who want to verify the source of funds for all transactions. Like Private Identity and Private KYC solutions, you should consider whether you interact with personal information. If your application relies on a KYC Token, you should consider whether the due diligence conducted by a third party satisfies any independent obligations you may have.  

• Access Control Implementations: Restrict which users can or cannot access or interact with an application based on a set of predefined criteria (e.g., specific addresses, IP addresses, devices, user behavior, etc.). For example, users can generate valid proofs demonstrating that they are included on an allowlist based on predefined criteria. Conversely, they can prove they didn’t interact with restricted addresses or applications.  Like Private Identity and Private KYC solutions, you should consider whether you interact with personal information. You should also consider the appropriate lists and geographies that may need to be controlled based on your application as well as the required documentation to explain and justify your restrictions.

No matter your application, sanctions laws as well as global consumer protection laws and regulations may apply, regardless of whether your application benefits individuals or businesses.

‍

What are portal contracts?

Portal contracts are the basis for the facilitation of communication between Ethereum Layer 1 and the Aztec network; Portals allow assets issued on Ethereum Layer 1 to be brought to Aztec. A Portal contract defines (1) which assets users are allowed to link to Aztec; (2) the requirements or conditions under which users can interact with the Portal contract; and (3) the Layer 2 actions users can perform with assets that have been linked via the Portal contract. You may want to develop and deploy a Portal contract as part of your application on the Aztec network—Aztec will not operate or otherwise control any Portal contracts. Additionally, Ethereum Layer 1, by design, has no native privacy. With this in mind, any inflows or outflows of assets to and from Ethereum will necessarily be public.

As the custodians of portaled assets, Portals have a responsibility to their users to ensure the security and integrity of these assets. To fulfill this responsibility, Portals may elect to have their own internal governance mechanisms to independently decide which Rollup contract instance to recognize as the canonical Aztec network. This allows Portals to reject upgrades that they deem unsafe or not in the best interest of their users, even if the Aztec governance process succeeds. This provides an additional layer of protection against potentially harmful changes. If you intend to deploy a Portal contract, you should consult with your legal counsel about whether there are any additional laws or regulations applicable to your Portal in addition to the application you are developing.

What kind of risk management and due diligence is recommended with respect to Aztec upgrades?

As a developer, you are encouraged to do your own research when building on Aztec. Protocol upgrades are not a “one size fits all” solution. You are responsible for subscribing to Aztec news bulletins, relevant online groups, and GitHub resources and insights in order to best determine whether an upgrade is best for your application. 

Portals operate using their own governance and control mechanisms outside of Aztec’s governance procedures. For example, if an upgrade to the Aztec network is planned and, as a developer, you wish to reject an upgrade to your application built on Aztec, you may initiate a forced exit, or stay on the older version In this instance, it is critical to be aware of when an Aztec upgrade is planned. There is a degree of self-governance here that must be balanced by risk management diligence. You should consult your legal counsel about any risks associated with accepting or rejecting any specific upgrade to the Aztec network and how your choice may affect your users.

What kind of risk management and due diligence is recommended when depositing and withdrawing from Aztec to Ethereum?

The appropriate risk management and due diligence for your Portal or application will vary based on the nature of activities you’re conducting or facilitating. In general, the following are recommended risk management measures to consider when depositing or withdrawing assets from Aztec to Ethereum. We’ve linked blockchain analytics tools below to aid these diligence measures—please be aware there are many analytics tools available for these purposes, and you should do your own research to ensure you use the tool best suited to your purposes and risk level.

‍

Front-End

• Check the Ethereum address that is depositing/withdrawing funds is not a sanctioned address.
• Check the Ethereum address to determine whether it has interacted with a sanctioned address, and determine whether any such interaction is supportable by you under your risk management policy.
• Conduct geolocation/IP address screening to confirm not a comprehensively sanctioned jurisdiction that is applicable to you.

‍

L1 Smart Contract

• Check the address depositing (can be different to msg.sender) is not on a sanctions list from an oracle contract e.g., TRM Labs or Chainalysis.
• Add a method to revoke the deposit (in case a user cannot claim funds on L2).
• Consider implementing a delay for withdrawals to be able to pause if a suspicious activity or a hack happens (as implemented by Aleo).

‍

Aztec Smart Contract

• Consider off-chain KYC or zk-KYC (like zkPassport or Keyring) on the individual claiming funds, depending on your specific requirements.
• Consider introducing a delay when processing claims to check against suspicious activity.
• When withdrawing, consider some of the following options:
  
  • Off-chain KYC or zk-KYC which check that the individual initiating withdrawal is:
    
    • From a non-sanctioned country;
    • Non sanctioned themselves; and
    • Not on any politically exposed list that is relevant and actionable under your risk management policy.
  • Check that the L1 withdrawing address is not sanctioned (do a storage proof on an L1 oracle contract) or maintain a similar contract on Aztec. (This check can also happen on L1 but then funds would be stuck).
• Consider allowing access to “compliant tokens” only (i.e., tokens that have either integrated note attestation or conduct some kind of compliance check on every transfer or shield operation based on certain thresholds with rate limits).

‍