DeFi is at a fork in the road: Either we continue building in an entirely open yet isolated ecosystem, or we begin bridging the gap between traditional finance through a willingness to engage with regulation and compliance. We believe the latter is essential for our industry to grow into a place where eventually, all of the world’s financial products and services are run on-chain. This world is compatible with what makes DeFi great – composability and its non-custodial nature.

Yet this world requires a new set of trust assumptions. For example, how can on-chain capital pools be trusted to exclude bad actors? Violet’s mission from inception has been to evolve trust. One of our earliest contributions to the industry was the Humanbound Token, pioneering compliance and robust sybil-resistance on-chain through human trust. We are now expanding on this early infrastructure to provide best-in-class, TradFi-level compliance guarantees directly on-chain, including KYC/B, global sanction list monitoring, geofencing, on-chain analytics, and multi-factor authentication to prove identity continuity.

It is the most comprehensive compliance stack in DeFi, and we are excited to announce Mauve – the first registered, compliant DEX – as the first product built on Violet. As a DEX, users benefit from the non-custodial architecture with immediate settlement and no intermediaries. Mauve provides TradFi-level compliance guarantees, enabling new actors to join the market and allowing Mauve to support a vastly expanded universe of assets. Eventually, Mauve will evolve into an on-chain backend for regulated financial services.

We envision Mauve becoming the seed within the compliant DeFi universe and will share a lot more information regarding its exact functionality and implementation details soon. In the meantime, we spoke to Fortune’s Jeff Roberts about where we are in our journey and what is ahead:

Coinbase Ventures joins $15M bet on new crypto exchange Mauve-a 'response to the FTX fallout' | Fortune Crypto

Crypto exchange Mauve seeks to offer the best features of DeFi combined with the compliance elements of traditional finance.

https://fortune.com

In addition, we are humbled and grateful to announce additional funding of $11.5M for an aggregate of $15M following our funding in early 2021, as we continue on our journey to help shape a more robust and sustainable DeFi ecosystem.

Thank you to Ethereal Ventures, FinTech Collective, and Balderton Capital for leading this new funding round, as well as Inflection, Coinbase Ventures, Brevan Howard, Compound, Lattice Capital, Goldentree Asset Management, and Wintermute for their participation.

We are equally excited about welcoming world-class founders and operators, including from OpenSea, Element Finance, Flashbots, Argent, Spruce, Ceramic, and Privy.

Special thanks to BlueYard Capital for their continued support.

*Mauve has submitted an application to register as a Virtual Asset Service Provider. The application is currently pending.

It’s important to dig in on what we think “compliance” means because that term is thrown around a lot without enough clarity. We approach “compliance” in web3 and crypto at a fundamental level – the details flow directly from the government’s overarching purposes of protecting investors and consumers from bad actors who would otherwise cause them harm. There are many detailed, frequently old, rules, regulations, processes, and controls that exist currently for many different industries, but the reason for those requirements is to further the broader protective spirit and purpose. We think too much time is spent debating the nuances around the rules (e.g., whether they apply, whether an entity can actually comply), and too little time is focused on how to make our products “safer” to avoid innovation-crippling, detailed regulation that is clearly on the horizon.

Like it or not, all signs point to mandatory “compliance” coming for most layers in web3, albeit in different forms, and the only real question is whether we can collectively meet government expectations without departing from core web3 values like real privacy. We are at a critical moment in our history: governments are still figuring out how to handle crypto and web3, and we have time to showcase how our technology can enable a better and safer version of life online – while putting user privacy front and center. 

That’s why we built Violet alongside Humanbound Tokens (HBTs). We think Violet satisfies the spirit and purpose of government regulation generally as well as checking the existing, critical boxes in truly web3 and crypto native ways.

Violet remains in a closed-beta stage, and features described here may be in various stages of implementation and development. All features are intended to be live by the end of 2022. Please check our documentation or reach out to us on Discord if you are interested in the closed beta!

Violet is a Plug-And-Play, Comprehensive Compliance Solution

Violet is our compliance and identity management infrastructure that we will be able to readily customize and adapt as specific legal requirements change in the future. We’ve explained previously how we approached solving the hard problem of privacy-protective compliance, but it’s worth restating that we can confidently issue on-chain compliance credentials and access tokens confirming that a particular wallet is linked to a specific human that passed certain compliance checks without leaking any personal information on-chain or to the third party using Violet.

At this stage, Violet is in closed beta, but we are developing it into a plug-and-play, off-the-shelf solution that any protocol, platform, service, or product can readily utilize regardless of industry. Relying on a user’s HBT and their consent to Violet’s checks, we are able to do the following instantly every time our contracts are called for a registered wallet address, and we only issue the required access token if the checks are passed to our satisfaction:

• Know Your Customer (KYC): We confirm a user’s identity during their HBT enrollment, and we use 2FA to ensure that the same human that enrolled is the one conducting each and every transaction that requires Violet. (We are actively working to add Know Your Business Customer (KYBC) capabilities!)

• Traditional, Off-Chain Sanctions: We screen users against current sanctions lists before issuing an HBT, and we continue to perform these traditional checks for every new transaction involving that human as well as every 24 hours per industry standard. (It’s not sufficient to screen a person once for sanctions or AML compliance as the lists and people’s activities that may subject them to sanctions are always evolving.)

• Know Your Transaction (KYT): We screen registered wallets directly with sophisticated partners to ensure that no on-chain activity has occurred that would prohibit the transaction – such as the wallet address being on a sanctions list even if the human isn’t – or that materially increases the risk as a transaction partner in a way that we cannot support.

• Anti-Money Laundering (AML): AML requirements generally are risk based and ongoing obligations, and what’s appropriate will depend on your protocol, platform, product, or service. We reasonably believe Violet will meet these risk-based requirements in many circumstances based on our combination of KYC, traditional sanctions, and KYT. Through detailed KYC and our 2FA requirements, we have a reasonable belief that we know the true identity of the human behind every transaction, and we persist that data in an encrypted off-chain storage vault. Second, through a combination of our traditional sanction screening and KYT process, our system is reasonably designed to detect and enable reporting of suspicious activity.

If your protocol, platform, service, or product requires you to file Suspicious Activity Reports, you would need to separately get affirmative consent from the human behind the wallet and prove that consent to us before we’d be able to provide the personal information required to file such a report. We take our user’s privacy extremely seriously, and we require all data access and disclosure to be done on an informed-consent basis absent a legal order compelling disclosure.

Violet offers a comprehensive, on-chain and off-chain compliance picture that you can rely on even though it is conducted programmatically and anonymously from your perspective. We will never compromise on that last point absent informed consent from a particular user – our native web3 compliance service only works if we are truly trustworthy and stand behind our data access promises, which we intend to prove to our users in their dashboards in real-time.

How Does Violet Address KYC Requirements?

Knowing and verifying a user is central to preventing money laundering and other types of financial crimes. One example (out of many) comes from the Bank Secrecy Act, which according to the Federal Financial Institutions Examination Council’s BSA/AML manual, requires certain financial institutions to collect and verify things like a customer’s (1) name and residence, (2) date of birth, (3) contact information, and (4) an identification number.

But KYC-like requirements are not limited to traditional financial institutions. Under the Markets in Crypto-Assets Regulation (MiCA), the EU will require customer due diligence for crypto-asset service providers, which includes identifying customers based on documents and verifying the information. EU DeFi regulation is anticipated in 2023, and MiCA is expected to be a reference point even if the regulations differ in some ways.

Zooming out even farther, there are laws requiring various levels of KYBC in an effort to curb fraudulent sales and product practices. For example, with respect to commerce, the EU’s forthcoming General Product Safety Regulation will impose various types of KYBC on online platforms. And the United States is following suit with bills like SHOP SAFE that would require certain platforms to verify the identity and contact information of certain sellers of goods. KYBC support is coming quickly to ensure those requirements can likewise be met by anyone using Violet.

There’s no doubt that global policy overall has moved towards more identity verification in order to combat illicit financial activities and fraudulent activity online. Violet intends to functionally satisfy these requirements as they evolve, and broadly speaking, we believe it meets the requirements of existing laws.

As part of the HBT enrollment process, a user’s wallet address, name, date of birth, location of birth, nationality, ID card type, ID card expiration, ID card issuer, ID card number, mobile phone number, and facial image are all used to verify the user’s identity, although biometrics are purged immediately after. We then store user personal data in “atomic” Verifiable Credentials. A second authentication factor is enrolled at registration and must be used to verify each and every future transaction – this is a critical step required for identity continuity so to avoid wallet “whitewashing,” and that solutions are incomplete if they do not require confirmation of a second authentication factor for each transaction.

How Does Violet Address Sanctions Requirements?

Everyone in the world is subject to sanctions laws, both people and businesses. The United States, United Kingdom, and Europe often receive the most attention for their sanctions lists and policies. For example, all three groups have adopted comprehensive sanctions against Russia and its citizens in response to the war in Ukraine and the Democratic Republic of North Korea related to nuclear weapons development. Critically, government sanctions regulators now list both people and businesses under traditional identifying criteria (e.g., a name) AND wallet addresses, including smart contracts themselves (see: Tornado Cash).

Violet is built to send the most trusted sanctions compliance signal possible. Before permitting each and every transaction, we confirm that (1) the human behind the transaction has not been sanctioned, and (2) the associated wallet address for the transaction has not been sanctioned.

How Does Violet Address AML Requirements?

Traditional AML rules – like those imposed by the Bank Secrecy Act in the United States – incorporate KYC and sanctions compliance, but can require more. FINRA Rule 3310, for example, provides that entities subject to the Rule must use “risk-based procedures” for ongoing diligence to (1) understand “the nature and purpose of customer relationships” in order to develop a risk profile, and (2) monitor transactions “to identify and report suspicious transactions” in addition to maintaining and updating customer information.

Again, these are risk-tailored requirements, so exactly what’s necessary will depend on the nature of your product, its use case, and the nature of your users. Violet is capable of providing an ongoing, 360-degree view of a human at the time of every transaction, covering both on-chain and off-chain risk vectors. We have the ability to use a default risk score to determine whether a transaction may go forward under our credential, which we set at a level that gives us sufficient confidence the transaction is not illicit.

We would not disclose our risk score to anyone other than the HBT credential holder absent explicit, informed user consent or a legally binding order – we would treat these scores just like user data.

“Compliance” as an Opportunity

We see “compliance” as an opportunity for crypto and web3 to prove that you don’t need stringent, detailed government regulation of every product or service in order to meaningfully protect investors and consumers. Out of the box, HBTs + Violet will provide more protection against illicit and fraudulent conduct than any similar solution we are aware of in web2 or web3 without compromising a user’s privacy. By leveraging off-chain and on-chain information, we have a comprehensive understanding of a person’s risk, but critically, we do all of that without revealing the person’s identity to anyone else – it’s up to the person whether they want to identify themselves for some other purpose.

Let’s make crypto safer on our own, leveraging financial-institution level “compliance” that comes without mass data exposure or significant friction, and spend our time showcasing how web3 and crypto are fundamentally better ways to organize society.

*               “Our key primitive is accounts, or wallets, that hold publicly visible,                non-transferable (but* possibly revocable-by-the-issuer) tokens. We refer to                the accounts as ‘Souls’ and tokens held by the accounts as ‘Soulbound                Tokens’ (SBTs).”

These accounts or wallets could refer to almost any container that holds information – blockchain accounts, a Web5 wallet or an implementation yet to be discovered – and we agree that it is helpful to think about identity this way. The DeSoc paper, however, attached “Soul” to an entity that distributes identity-related information as opposed to the human who owns the account or wallet and receives the information:

               “The Ethereum Foundation could be a Soul that issues SBTs to Souls who                attended a developer conference.”

The first foundational issue with this concept is what happens if access to a wallet is lost. A wallet could also be stolen or sold. Consider rotating wallets: Is Soul rotation a thing? In fairness, the co-authors clarified their views, and we now think SBTs can be more accurately described as “Community-bound Tokens.” 

In describing SBTs, the co-authors introduced the concept of community recovery with SBTs bound to the intersection of specific social circles, communities or groups. For example, if authors of academic papers were to receive SBTs, Vitalik could be uniquely identified, with the help of his co-authors, as the writer sitting at the intersection of a set of papers he co-wrote.

The second foundational issue is the transferability of tokens. Non-transferability is a very desirable property that should be on the top of the list of specifications when dealing with identity. It is key to the design of many reputation systems that rely on the continuity of the identity.

Viewing SBTs as community-bound tokens helps us understand how these tokens can be bound to a person even if they are transferable. Assuming the intersection of your social circles narrows down to a person, even if the SBTs get transferred, you will always be able to prove that you are you through your communities and claim the tokens back. This makes them in theory not appealing at all to any potential buyer. Transfers can still happen though and have disastrous consequences, even if recovery happens quickly after.

Non-transferability is a difficult problem to solve. Here’s an example: imagine a token is bound to a wallet held by Alice, and Alice sells her wallet to Bob. He would be able to impersonate Alice even though the token can not be transferred from her account. Interestingly, using Verified Credentials (VC) and Decentralized Identifiers (DIDs) do not solve this problem either.

So what if we take the view that a human IS the soul? Humanbound is a primitive that can be used to issue a token tied to a human instead of just a wallet. Although communities and social circles are part of what makes you who you are, in a way they are only a part of your identity. You might restart your life entirely – change your career and move to a different country – but this does not affect the ability for border control to identify you. For their purposes, you are the same person. Our different social circles also evolve with time and relying on them for securing your identity may be tedious in the future.

More on how Humanbound works here. We are excited to hear your thoughts! Head over to our Discord to participate in the conversation or drop us a note on Twitter.

Quick refresher: HBTs are tokens that are tied to a human, rather than to a wallet. Through multi-factor authentication we ensure identity continuity across on-chain transactions – while preserving privacy through encrypted off-chain data storage. Violet is our highly customizable compliance and identity management infrastructure. The purpose of Violet is to provide a standardized method to issue and authenticate compliance credentials on-chain.

In this post, we wanted to detail how we think about data protection and privacy not just with HBTs but also with the compliance challenges Violet is addressing. Using HBTs and Violet, you can readily implement identity-based compliance in web3, as much or as little as you want, while preserving user anonymity – let’s unpack how that’s possible, and where we can go from here.

Violet = Native Web3 Compliance

Regulatory and compliance requirements affect everyone, including web3 companies, protocols, and our users. The Tornado Cash sanctions are a stark example of what can happen when regulators confront a new technology they are convinced is a problem. And most crypto users have experienced at least one rug pull or pump-and-dump scheme. These are real issues that need to be solved.

We started building Violet to help solve those problems by focusing on identity and compliance management on Ethereum. We want to provide optionality for compliance in a decentralized, programmatic, privacy-preserving way. It’s our belief that users and businesses should have the ability to meet existing and future legal or regulatory requirements. If you aren’t interested in compliance or think the government should keep out of crypto entirely, we aren’t here to convince you otherwise – we equally support your right to engage in transactions based on your own risk assessment and support the developers building those solutions. But we firmly believe in choice, and providing compliance optionality in web3 will benefit everyone through reduced fraud and government antagonism.

Compliance is really hard to address in a web3 native way. User anonymity is hard to maintain because a lot of legal obligations depend on significant knowledge about, and verification of, the person that wants to engage in a transaction. Architecturally, a flexible compliance infrastructure is hard to build because the laws and regulations are all different: know your customer requirements, know your business customer requirements, know your transaction rules, sanctions rules, anti-money laundering rules, obligations like the transfer of funds regulations, plus the innumerable new laws being debated.

We believe we’ve solved these issues by combining the best of on-chain and off-chain technology. Today, we can confidently issue credentials and access tokens confirming that a particular wallet is linked to a specific human without leaking any personal information on-chain. In the future, we imagine evolving this platform to increase privacy even more using zero-knowledge proofs.

Violet = User-Controlled Privacy

Compliance is never more important than protecting and preserving user privacy. Fundamental to web3, and to us, is that users own their data and personal information, not Violet. We’ve filed regulatory comments making our position public (check Matt’s Twitter for the filing!), and we will continue to loudly stand behind that foundational principle.

In developing HBTs and Violet’s compliance approach, we made a few core decisions about how best to protect user data:

• We will never store personal information on-chain.

• We rely on an encrypted, off-chain data vault, hosted by Privy, where identity and compliance information is securely kept. Data is stored in the cloud, encrypted, and neither Privy nor the cloud provider ever have access to plaintext data. We maintain an audit log of all access to your data.

• Only you and Violet have permission to access your unencrypted data. We are committed to transparency on this topic – check out our Privacy Policy and Guidelines for Third-Party Information Requests.

We think these were the right decisions, and let’s talk about why.

First, HBTs were designed with limited on-chain disclosure – only the token ID is stored on-chain – to provide you with maximum privacy protections. It’s up to you what personal information you share with the world or a transaction counterparty – if you obtain an HBT, a transaction using your credential only discloses your wallet address paired with an access token signaling that you, the human behind the wallet, have registered with Violet and, if you engage in a future transaction, that you meet whatever is required for that particular smart contract.

Second, to eliminate personal information leakage on-chain, HBTs and compliance checks rely on an encrypted, off-chain data storage system. Our Privacy Policy and documentation specifically list what’s currently stored in the off-chain vault. We store user personal data in “atomic” Verifiable Credentials. We are working to allow users to use and compose these credentials in order to give them the freedom to choose which data they want to disclose to third parties directly without Violet being involved.

Third, we have limited access to unencrypted user data to everyone other than the user and Violet. All data collected at registration is purged by our verification partner immediately after enrollment, and our compliance partners are not permitted to access or use your data for any purpose other than running the compliance checks that you have agreed to. Users have routine “read” access to their data through the self-service portal, which we included at launch so users know, at any time, what’s being stored in their data vault.

We intentionally made the decision that Violet should have a set of keys to the encrypted data vaults for expressly limited purposes. We did not make that access decision lightly. To be clear: other than the compliance checks users ask us to run for them, Violet will not access user unencrypted data unless we are legally required to do so under compulsory legal process. Which begs the question: “what do you mean by compulsory legal process?”

Governments and private lawyers routinely try to figure out who is affiliated with a particular wallet address, especially when the wallet address is connected to a bad act like fraud. Identity services, whether centralized or decentralized, are ready targets for those legal demands whenever they are affiliated with a suspect wallet address. Our expectation is that anyone obtaining an HBT from us isn’t a bad actor and won’t be receiving such a request, but sometimes mistakes happen.

We kept access to user unencrypted data in order to help resolve these demands for our users, otherwise they’d be forced to respond to it personally or risk additional legal penalties in the form of contempt. And to be blunt: web3 ultimately needs governments to accept the innovation, which at a minimum requires acknowledging their legal demands specifically targeted to suspected bad actors’ wallets. Our full approach, and strong commitment to our users about disclosing these requests, is available here.

Lastly, we wanted to express our firm belief that informed consent is critical. For example, we would never mint non-transferable tokens to a user’s address or on their behalf without their expressed consent. We are not interested in sharing user data, and in no case would we share it without their prior permission.

Violet’s Next Steps

We are very excited about the future of HBTs and Violet! True to our ideals of optionality, choice, and informed consent, we are actively working to expand the user customization options for Violet. Here are a few examples of projects we have in mind, and how we are thinking about them:

• User-Only Access to Unencrypted Data. We recognize that users may not want or need us to assist with legal access requests and would opt to eliminate our access to their unencrypted data for that purpose and others. We are actively working on a way to provide this optionality while maintaining the compliance capabilities.

• User-Accessible Audit Logs. We believe users should not only be able to see their stored data in realtime, but they should be able to see for themselves the audit logs confirming the access they agreed to. There shouldn’t be secrets from users about who accessed their data or why.

• Expanded Compliance Services. There’s more to compliance than verified identity and sanctions. We are focused on infrastructure that would facilitate those different checks in our privacy protective way.

HBTs are tokens that are connected to a unique identity. In this primitive, identity properties are available off-chain and continuity is guaranteed through robust Humanbound authentication. This interpretation of web3 identity combines individuality and context, producing a composable yet unique primitive capable of use across a wide ecosystem.

Debates on identity are routine, specifically “Soulbound Tokens” (SBT) have been a recent center of attention. SBTs are an important innovation, yet they fall short by being tied only to an account as opposed to an identity. More on how we think HBTs improve on SBTs here.

Enter Humanbound

Head here for Humanbound Docs to read up on implementation details, and how data is encrypted, processed and stored.

The HBT design is simple: we mint tokens bound to an account upon identity verification and make sure that the account remains bound to this identity. The second step is critical – it introduces the concept of authenticated transactions to ensure continuity of identity.

Identity data is encrypted and stored securely off-chain. Moreover, it is expressed in verifiable credentials (VC), ensuring composability with other applications built using the same standard. This makes HBT the first simple, privacy preserving off-chain identity representation for web3, and we hope it can evolve into the first widespread usage of VCs.

There are many reasons to be excited about HBTs:

• Proof of personhood to build sybil resistant governance mechanisms or airdrops

• Secure DAO contributor payments

• NFT artist verification to increase buyer safety

• Compliant identities in DeFi to grow regulatory trust and engage institutional liquidity

To achieve their purpose, HBTs must be tied to strong authentication. Generally, strong authentication is considered to require at least two out of three categories: 1) knowledge - something you know such as a password, 2) inherence - something you are such as your fingerprints, or 3) possession - something you own such as your mobile phone. Hence the process of getting an HBT is as follows:

1. Successful wallet authentication and subsequent identity verification actives minting of an ERC721 into a user wallet

2. Enrolment of second factor authentication ensures identity continuity and going forward is required to e.g. make changes to the identity data. Initially, this is an SMS OTP

Here is how you can get your Humanbound Token:

1. Authenticate wallet ownership on Humanbound.xyz

2. Verify your phone number to enroll as your second factor authentication method, tying your authenticated wallet to your identity

3. Verify your identity by validating your identification documents and completing liveness detection with our identity verification partner Persona

4. Mint HBT on the network of your choice. We cover gas fees. This token is the on-chain representation of your identity; importantly it does not hold or reveal any personal data

Data collected in the initial identity verification is only processed and not stored by Persona (including audit logs). Instead, Violet takes custody of the data, which is stored off-chain via Privy. Balancing data reusability and privacy is core to Violet and Privy handles data storage, encryption and access control. Using Privy enables a third party to ensure that user data handled by Violet is always encrypted end to end and only available to permissioned parties. We take data privacy very seriously. Head here for a simple explanation of how we process and store data.

Personal data, once verified, is formatted in VCs, which are accessible in the Humanbound dashboard upon verification and HBT minting. Access is secured through proving wallet ownership and successful second factor authentication. Violet’s access to your data is regulated through our privacy policy.

Note that this is an early release and we are excited to hear in what direction you all would like to take Humanbound. A few more details on how we imagine the future of Humanbound:

• Multi-address and multi-chain support

• Support for additional (decentralized) authentication methods

• Adding support for Verifiable Presentations to allow for more easy export of user VCs

• Integration with decentralized storage technologies like IPFS to store identity data

• Client side identity data encryption using user keys

• Robust APIs for auth and data access

• ZKP import and export

We are excited to hear your thoughts! Head over to our Discord to participate in the conversation or drop us a note on Twitter.

While we are most excited about catalyzing institutional participation across DeFi in the near term (to help the space grow and become more robust), we believe Violet will serve as a primitive for many use cases.

Generalizable and composable on-chain credentials are a key design pattern in our system which we use to prove characteristics or behaviours about individuals while preserving their privacy. However in order to support reusability and custom logic on-chain for a wide range of different credentials we have built a new framework we want to share here.

Enter the Extendable Framework

The Extendable Framework is a novel smart contract development pattern to allow dynamic and modular runtime extensible contracts that are upgradeable, reusable and composable. Builders can flexibly add or remove functions from your contract, update existing logic and extend your smart contract interface to support a growing set of use-cases.

Like the commonly used Proxy pattern refined and popularized by OpenZeppelin, upgradeability is a core tenet to the pattern. In the Proxy pattern, a contract consists of two components, a Proxy which acts as the facade and entry point for transactions, and an implementation, which sits behind the Proxy but contains all the functionality and logic.

We’ve built on top of innovations like this to improve the way that upgradeability can be performed by separating the contract into more discrete component contracts where each section of a contract can be independently modified and updated without upgrading the entire thing.

The Diamond Standard provides a similarly great approach to smart contract upgradeability and is also another key inspiration for our work here. We wanted to create a framework that could be as easy to implement as regular smart contracts that leaned heavily into reusability, modularity and flexibility, without introducing any additional difficulty in use or development alongside the added complexity.

With that in mind, the Extendable Framework was born. Let’s take a deeper look at how we achieve this.

Let’s dive in

The Extendable smart contract pattern allows your contract to be extendable with smart contracts called Extensions that can be selectively added and removed from your contract. But how does it work and how can you make use of this pattern?

To make your contract Extendable, simply inherit the Extendable.sol contract:

`contract YourContract is Extendable {}`

This provides your contract with all the functionality to allow it to be extended. Your contract then becomes a collection of extensions as modular functional units instead of your usual monolithic contract codebase.

Instead of writing functions for your contract you can now write Extension modules that can be reused across many different contracts. Extensions can be replaced in the case of upgrades, removed in the case of deprecation, and added where new functionality is needed. There are also many more ways to use extensions depending on your needs. Each extension can read and write state as normal through a different state storage access pattern.

State variables are defined inside separate modules called Storage Modules. These are library contracts that provide access to any state variable that you define. However instead of declaring and defining them as regular storage variables in your smart contract, they are declared as structs that your Storage Module will reference to whenever you need to read from or write to it.

The separation of layers between logic and storage means that you can write any kind of functional logic to be able to access state variables as usual but with the powerful flexibility afforded by your contracts being extendable.

This means that deploying similar contracts like tokens will be much cheaper as you can simply re-use common token logic such as ERC721 or ERC1238, instead of having to redeploy the exact same code. Your contracts will have static addresses so upgrades to logic won’t break any integrations, similar to common Proxy patterns, and upgrades can be performed to small or large parts of your contract code through selective extension replacement.

Get involved!

The Extendable Smart Contract pattern provides a design approach for smart contract development and maintenance that solves many of the problems in smart contracts and enhances many of the benefits. By making your contracts Extendable you can build fully flexible, dynamic contracts that are robust and future-proof with maximal control over runtime functionality. Start building with the Extendable pattern:

• GitHub repo

• Early documentation

Note that this is early work so we’d love to hear feedback and welcome contributions to the framework. We’re open sourcing our reference implementation early so we can continue the build, develop and iteration of this approach with the community in hand. We think smart contract design patterns are paramount in supporting the evolving complexity in decentralised applications but also importantly keeping the community safe through vetted and standardised patterns.

Stay tuned for a future post on implementation, as well as many ideas for improvements we are looking forward to sharing with you all soon.