
Today, the whole team is extremely excited to announce that we have deployed Unlock on [Optimism](https://www.optimism.io/about), making it the first NFT-based protocol to be available on 5 networks, including a roll-up L2!

## Ethereum's future

Gas fees on the Ethereum mainnet have now been outrageously high for more than a year, moving Ethereum away from its target of being a "world computer" accessible to everyone with an internet connection. It also makes use cases like Unlock much harder to use: our membership NFT should work well for $1 as well as $10,000 memberships!

Don't get us wrong: in some ways, high gas fees are a good problem to have for the Ethereum community. They mean that demand for the very precious block space is much higher than the available supply.

That said, the community has realized this for a long time, and multiple "layer 2" solutions have emerged. Vitalik Buterin [wrote many times](https://vitalik.eth.limo/general/2021/12/06/endgame.html) about why he believes that "roll ups" are the way to scale beyond the limited block space, and we agree!

## Unlock on Optimism

A few months ago, we launched Unlock on [xDAI](/blog/xdai), on [Polygon](/blog/unlock-on-polygon) and more recently on the [Binance Smart Chain](/blog/binance-smart-chain). All of these are great solutions for anyone who wants to deploy a lock, even today! They generally reduce some requirements around permissionlessness in favor of greater usability and much lower fees.

However, roll-ups represent an opportunity to find another balance between cost and security and we believe Unlock should embrace these too!

So, starting today, Unlock is available on Optimism. We have deployed the same contracts deployed on all the other chains and our front-end fully supports it! For this initial release, locks deployed on Optimism will not yield UDT governance contracts, but we hope to enable that by the end of the year! Get started by [going to the Unlock Dashboard](https://app.unlock-protocol.com/dashboard) and select "Optimism" in the network dropdown!

We can't wait to hear what memberships are going to be unlocked on Optimism :) Like always, please join our community and share your experiments with us!


The Unlock Protocol is now available on Optimism, making it the first NFT-based protocol to be available on 5 networks, including a roll-up L2!

The Ethereum world is moving to Layer 2, Unlock paves the way

Unlock is available on Optimism

<p>Today, the whole team is extremely excited to announce that we have deployed Unlock on <a href="https://www.optimism.io/about">Optimism</a>, making it the first NFT-based protocol to be available on 5 networks, including a roll-up L2!</p>
<h2>Ethereum's future</h2>
<p>Gas fees on the Ethereum mainnet have now been outrageously high for more than a year, moving Ethereum away from its target of being a "world computer" accessible to everyone with an internet connection. It also makes use cases like Unlock much harder to use: our membership NFT should work well for $1 as well as $10,000 memberships!</p>
<p>Don't get us wrong: in some ways, high gas fees are a good problem to have for the Ethereum community. They mean that demand for the very precious block space is much higher than the available supply.</p>
<p>That said, the community has realized this for a long time, and multiple "layer 2" solutions have emerged. Vitalik Buterin <a href="https://vitalik.eth.limo/general/2021/12/06/endgame.html">wrote many times</a> about why he believes that "roll ups" are the way to scale beyond the limited block space, and we agree!</p>
<h2>Unlock on Optimism</h2>
<p>A few months ago, we launched Unlock on <a href="/blog/xdai">xDAI</a>, on <a href="/blog/unlock-on-polygon">Polygon</a> and more recently on the <a href="/blog/binance-smart-chain">Binance Smart Chain</a>. All of these are great solutions for anyone who wants to deploy a lock, even today! They generally reduce some requirements around permissionlessness in favor of greater usability and much lower fees.</p>
<p>However, roll-ups represent an opportunity to find another balance between cost and security and we believe Unlock should embrace these too!</p>
<p>So, starting today, Unlock is available on Optimism. We have deployed the same contracts deployed on all the other chains and our front-end fully supports it! For this initial release, locks deployed on Optimism will not yield UDT governance contracts, but we hope to enable that by the end of the year! Get started by <a href="https://app.unlock-protocol.com/dashboard">going to the Unlock Dashboard</a> and select "Optimism" in the network dropdown!</p>
<p>We can't wait to hear what memberships are going to be unlocked on Optimism :) Like always, please join our community and share your experiments with us!</p>



The Defiant, headed by CEO, journalist, and author Camila Russo, is “The Bloomberg of DeFi.” (Russo should know; she’s a former Bloomberg journalist.) Fiercely independent from its name to its actions and its editorial voice, The Defiant is a rapidly-growing media network that spans newsletters, videos, podcasts, and articles covering decentralized finance (DeFi).

The Defiant funds its operations through paid subscriptions from readers as well as through sponsorships. True to its journalism roots, The Defiant does not accept any paid article placements in editorial content, nor does it accept compensation for tweets or retweets.

[See the full case study](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/The%20Defiant%20-%20Unlock%20Case%20Study.pdf).

[![The Defiant thumbnail](/images/blog/thedefiant-case-study/thedefiant-thumbnail-2.png)](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/The%20Defiant%20-%20Unlock%20Case%20Study.pdf)


When The Defiant was looking for a crypto-native way to monetize its content and newsletter subscriptions, it turned to the Unlock Protocol.

Newsletter Monetization at The Defiant | Unlock Case Study

<p>The Defiant, headed by CEO, journalist, and author Camila Russo, is “The Bloomberg of DeFi.” (Russo should know; she’s a former Bloomberg journalist.) Fiercely independent from its name to its actions and its editorial voice, The Defiant is a rapidly-growing media network that spans newsletters, videos, podcasts, and articles covering decentralized finance (DeFi).</p>
<p>The Defiant funds its operations through paid subscriptions from readers as well as through sponsorships. True to its journalism roots, The Defiant does not accept any paid article placements in editorial content, nor does it accept compensation for tweets or retweets.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/The%20Defiant%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/The%20Defiant%20-%20Unlock%20Case%20Study.pdf"><img src="/images/blog/thedefiant-case-study/thedefiant-thumbnail-2.png" alt="The Defiant thumbnail"></a></p>



In an effort to provide more support to our community builders, members and supporters, we're launching a retroactive funding campaign. The short and sweet is that we want to support the supporters of the protocol in a way that is decentralized and open to the entire community to vote to decide who gets rewarded for their _past_ participation.

Unlock Inc is allocating 100 UDT each month to the community and, more importantly, we want to let the community decide who should get them, with the hopes that the community will allocate them to whoever had the biggest impact on the protocol in the previous month.

Here is how we're doing it:

- On the first of every month, we will create a new thread for nominations on [https://unlock.community/](https://unlock.community/). Anyone in the community is free to apply for themselves or someone else and explain why they should get some governance tokens. The only requirement is for the person to post the address that should receive tokens!
- On the 8th, we will close nominations and open a Snapshot vote for each and every address that was nominated. We will use a [quadratic voting strategy](https://docs.snapshot.org/proposals/voting-types#quadratic-voting) so that the number of voters matters (vs. just their token balances). Voting is off-chain and gas-less (free!)
- At the end of the voting period (8 days), Unlock Inc. will split the number of tokens between all the addresses, using their relative share of votes. We will distribute these tokens on the Polygon network in order to reduce the impact of high gas fees.

And it starts... [today!](https://unlock.community/t/retroactive-funding-november-2021/199) We hope to do that every month for at least one year, but we will re-evaluate every quarter.

Our mission here is simple. We believe that the more adoption we have by builders and creators across the ecosystem, the stronger the protocol will become and the more we all benefit as a community. But not every contributor or project falls into our grant program or other means of support, so we feel this retroactive funding will help provide that additional support that is needed to grow our community.

We really put trust in the community and we hope you will all use that mechanism as a way to reward our active community members!


In an effort to provide more support to our community builders, members and supporters, we're launching a retroactive funding campaign.

The community will pick the best contributors to the protocol every month!

Retroactive Funding

<p>In an effort to provide more support to our community builders, members and supporters, we're launching a retroactive funding campaign. The short and sweet is that we want to support the supporters of the protocol in a way that is decentralized and open to the entire community to vote to decide who gets rewarded for their <em>past</em> participation.</p>
<p>Unlock Inc is allocating 100 UDT each month to the community and, more importantly, we want to let the community decide who should get them, with the hopes that the community will allocate them to whoever had the biggest impact on the protocol in the previous month.</p>
<p>Here is how we're doing it:</p>
<ul>
<li>On the first of every month, we will create a new thread for nominations on <a href="https://unlock.community/">https://unlock.community/</a>. Anyone in the community is free to apply for themselves or someone else and explain why they should get some governance tokens. The only requirement is for the person to post the address that should receive tokens!</li>
<li>On the 8th, we will close nominations and open a Snapshot vote for each and every address that was nominated. We will use a <a href="https://docs.snapshot.org/proposals/voting-types#quadratic-voting">quadratic voting strategy</a> so that the number of voters matters (vs. just their token balances). Voting is off-chain and gas-less (free!)</li>
<li>At the end of the voting period (8 days), Unlock Inc. will split the number of tokens between all the addresses, using their relative share of votes. We will distribute these tokens on the Polygon network in order to reduce the impact of high gas fees.</li>
</ul>
<p>And it starts... <a href="https://unlock.community/t/retroactive-funding-november-2021/199">today!</a> We hope to do that every month for at least one year, but we will re-evaluate every quarter.</p>
<p>Our mission here is simple. We believe that the more adoption we have by builders and creators across the ecosystem, the stronger the protocol will become and the more we all benefit as a community. But not every contributor or project falls into our grant program or other means of support, so we feel this retroactive funding will help provide that additional support that is needed to grow our community.</p>
<p>We really put trust in the community and we hope you will all use that mechanism as a way to reward our active community members!</p>



As a community-supported, free and open-source crypto tool suite, MyCrypto needed a solution to turn “users” into “paying users” to help fund future initiatives. In 2019, MyCrypto began looking for a way to offer MyCrypto memberships.

MyCrypto envisioned a future where, when community members offered their financial support, those supporters gained members-only access to exclusive perks in return for becoming a paying member of the community. After exploring a number of options (including building their own solution stack), MyCrypto found their answer in the Unlock Protocol.

[See the full case study](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/MyCrypto%20-%20Unlock%20Case%20Study.pdf).

[![MyCrypto thumbnail](/images/blog/mycrypto-case-study/mycrypto-thumbnail-3.png)](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/MyCrypto%20-%20Unlock%20Case%20Study.pdf)


MyCrypto implemented Unlock Protocol and turned "users" into "paying users" for their open-source suite of Ethereum management tools.

MyCrypto Paid Memberships | Unlock Case Study

<p>As a community-supported, free and open-source crypto tool suite, MyCrypto needed a solution to turn “users” into “paying users” to help fund future initiatives. In 2019, MyCrypto began looking for a way to offer MyCrypto memberships.</p>
<p>MyCrypto envisioned a future where, when community members offered their financial support, those supporters gained members-only access to exclusive perks in return for becoming a paying member of the community. After exploring a number of options (including building their own solution stack), MyCrypto found their answer in the Unlock Protocol.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/MyCrypto%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/MyCrypto%20-%20Unlock%20Case%20Study.pdf"><img src="/images/blog/mycrypto-case-study/mycrypto-thumbnail-3.png" alt="MyCrypto thumbnail"></a></p>



Blockchains like Ethereum exist to prevent recorded data from being altered. Once published, the content of a contract can not be changed. Only values stored by the contract itself can be updated (i.e. balance, owner, etc) but the code itself is immutable. However, the same address can still lead to different contracts. At Unlock, we are about to deploy the 10th version of our main contract but the [address](https://etherscan.io/address/0x3d5409cce1d45233de1d4ebdee74b8e004abdd13) never changed since day one. How are these upgrades made possible? black magic? blocks reorg?

## Proxies on Ethereum

A proxy is a piece of code that acts as an intermediary between the entity doing a request and the provider answering it. Instead of directly calling a program, you call the proxy that will take care of passing your demand and brings you back what you asked. As a provider, the proxy will take charge of handling all the incoming, forwarding only what asked.

On Ethereum, _proxy contracts_ are used to forward call to an end contract that does the heavy lifting - often called _implementation_. If you decide to change the way the contract behaves, you just need to point the proxy to a new implementation, and tell him to forward things there. Requests can still be sent to the same address (the address of the proxy) but the behaviour may have changed.

This pattern turns out very useful when developing a product like Unlock, because it allows us to upgrade contracts to provide new features, fix known issues, etc.

## Potential storage conflicts

Upgrading a contract is not like updating a web page though. Everything on-chain is unreversible and mistakes are very costly, destroying entire projects - and accessorily costing tons of gas for a simple upgrade.

One important risk is _storage conflicts_. On Ethereum, contracts have their own storage for persitent information. A simple token contract keeps addresses of all the holders in its storage. The storage lives in the almighty Ethereum Virtual Machine (EVM) and takes the form of a very long list, initially full of zeros. When a contract is compiled, each variable is assigned a _slot_ in the storage following their order in the contract. When data is stored, the EVM picks some of the zeros in the corresponding slots and replace them with the new value.

![](https://programtheblockchain.com/storage/fixed.png)

_Anatomy of a storage slot, from a good [write-up](https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/)._

When using a proxy, the calls are forwarded to the end/implementation contract, but the data is stored within the proxy itself. To know how to store it, the proxy reads variable from the end contract to define the slots. That means data will be kept when the end contract changes. That also means that if variables changes in the end contract, the storage layout ends up being modified. In certain cases, conflicts in slots can occur, making it impossible for the proxy to find existing slots - or even leading it to erase them.

To prevent this type of conflict in storage from happening, we at Unlock rely on the [Open Zeppelin upgrades library](https://docs.openzeppelin.com/upgrades/2.8/) to ensure that storage layout is compatible before proceding to any upgrade.

## Testing upgrades

Despite avoiding technical failures, we have to make sure to preserve existing features from our contracts during upgrades - and add some new ones! We have an extensive test suite to check that each function does what it is supposed to. However, many features of Unlock relies on external resources, tokens and oracle contracts which is harder to enforce. The complex set of dependencies is hard to recreate locally, so we came up with solutions to tackle it.

First, we developed a set of scripts that are used both for local development and multi-chains deployment. Powered by [hardhat](https://hardhat.org), we now have [tools](https://github.com/unlock-protocol/unlock/tree/master/smart-contracts/scripts) to deploy and configure our contracts, submit DAO proposals, upgrade contracts, etc. Before sending an upgade, we run relevant tests on a [local fork of Ethereum mainnet](https://hardhat.org/hardhat-network/guides/mainnet-forking.html), then proceed to an upgrade and finally run the test again against the upgraded version. That way we can check that our contracts behaviours are preserved after an upgrade.

```shell
$ yarn hardhat

AVAILABLE TASKS:

  ...
  deploy           	Deploy the entire Unlock protocol
  deploy:governor  	Deploy Governor Alpha contracts
  deploy:oracle    	Deploy UDT <> WETH oracle contract
  deploy:template  	Deploy PublicLock contract
  deploy:udt       	Deploy Unlock Discount Token proxy
  deploy:uniswap   	Deploy Uniswap V2 Factory and Router
  deploy:unlock    	Deploy Unlock proxy
  deploy:weth      	Deploy WETH contract
  ...
  gov:delegate     	Delagate voting power
  gov:submit       	Submit a proposal to UDT Governor contract
  gov:vote         	Vote for a proposal on UDT Governor contract
  ...
  impl             	Get the contract implementation address
  ...
  upgrade          	Upgrade an existing contract with a new implementation
  upgrade:prepare  	Deploy the implementation of an upgreadable contract
  upgrade:propose  	Send an upgrade implementation proposal to multisig
  ...
  verify           	Verifies contract on Etherscan
  ...
```

## Upgrading contract from another contract

Besides making our main contracts upgradeable, we started to add the upgrade logic inside our product itself. When you deploy a lock with Unlock, a new instance of the `PublicLock` contract (ERC-721) is created with the parameters you defined (name, token, etc). In Solidity, several patterns exist to [deploy a contract from another contract](https://github.com/clemsos/sol-upgrade-pattern/). The previous version of Unlock was using a _Minimal Proxy_ (EIP-1167). Instead of deploying the entire contract for each new lock created, a small proxy is deployed just to hold the data and forward calls to a main instance that deals with all the incoming. That allowed to save a non-negligeable amount of gas when deploying a new lock instance.

However, the minimal proxy approach _did not allow for upgrades_. We wanted all locks to benefit from the latest features available so we started to investigate how we could deploy a full proxy from a contract and **allow users to upgrade their locks** when new features were released. The problem was twofold: 1) allow all managers of a lock to upgrade themselves (keep things decentralized), 2) make sure upgrades are safe.

We used Open Zeppelin [TransparentProxy](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.3.0/contracts/proxy/transparent/TransparentUpgradeableProxy.sol) pattern, and added the following logic to our contract :

- when a lock is created:

  - deploy a proxy
  - point it to the latest implemtation

- when a lock is upgraded:
  - check if the caller is authorized as a lock manager
  - point to the new implementation

We decided to store a single [`ProxyAdmin`](https://docs.openzeppelin.com/contracts/4.x/api/proxy#ProxyAdmin) instance in our main contract that will take care of all the upgrade process. When `upgradeLock` is called, our main contract will check into the deployed lock if the caller is a lock manager. If yes, our proxy admin will proceed to upgrade the lock. If not, the upgrade will be rejected.

```solidity
/**
 * @dev Upgrade a Lock template implementation
 * @param lockAddress the address of the lock to be upgraded
 * @param version the version number of the template
 */
function upgradeLock(
  address payable lockAddress,
  uint16 version
) public returns (address) {
  require(proxyAdminAddress != address(0), 'proxyAdmin is not set');

  // check perms
  require(
    _isLockManager(lockAddress, msg.sender) == true,
    'caller is not a manager of this lock'
  );

  // check version
  IPublicLock lock = IPublicLock(lockAddress);
  uint16 currentVersion = lock.publicLockVersion();
  require(
    version == currentVersion + 1,
    'version error: only +1 increments are allowed'
  );

  // make our upgrade
  address impl = _publicLockImpls[version];
  TransparentUpgradeableProxy proxy = TransparentUpgradeableProxy(lockAddress);
  proxyAdmin.upgrade(proxy, impl);

  emit LockUpgraded(lockAddress, version);
  return lockAddress;
}
```

The various versions are stored in the contract with a version number and its corresponding implementation. For instance, lock managers can launch an upgrade by calling `upgradeLock(0x...lockAddress, 10)` to upgrade their lock to version 10 - or through the dashboard. For better compatibility, we forbid bumps of more than one version number (so version 9 to 10 works, but 8 to 10 will fail).

## Coming release

We are now finalising a new version of the lock template with more features and a few fixes that should come with the upgradeable version! Stay tuned :)


What are contract upgrades on Ethereum, and how we use, test and deploy them at Unlock

Making locks upgradeable

<p>Blockchains like Ethereum exist to prevent recorded data from being altered. Once published, the content of a contract can not be changed. Only values stored by the contract itself can be updated (i.e. balance, owner, etc) but the code itself is immutable. However, the same address can still lead to different contracts. At Unlock, we are about to deploy the 10th version of our main contract but the <a href="https://etherscan.io/address/0x3d5409cce1d45233de1d4ebdee74b8e004abdd13">address</a> never changed since day one. How are these upgrades made possible? black magic? blocks reorg?</p>
<h2>Proxies on Ethereum</h2>
<p>A proxy is a piece of code that acts as an intermediary between the entity doing a request and the provider answering it. Instead of directly calling a program, you call the proxy that will take care of passing your demand and brings you back what you asked. As a provider, the proxy will take charge of handling all the incoming, forwarding only what asked.</p>
<p>On Ethereum, <em>proxy contracts</em> are used to forward call to an end contract that does the heavy lifting - often called <em>implementation</em>. If you decide to change the way the contract behaves, you just need to point the proxy to a new implementation, and tell him to forward things there. Requests can still be sent to the same address (the address of the proxy) but the behaviour may have changed.</p>
<p>This pattern turns out very useful when developing a product like Unlock, because it allows us to upgrade contracts to provide new features, fix known issues, etc.</p>
<h2>Potential storage conflicts</h2>
<p>Upgrading a contract is not like updating a web page though. Everything on-chain is unreversible and mistakes are very costly, destroying entire projects - and accessorily costing tons of gas for a simple upgrade.</p>
<p>One important risk is <em>storage conflicts</em>. On Ethereum, contracts have their own storage for persitent information. A simple token contract keeps addresses of all the holders in its storage. The storage lives in the almighty Ethereum Virtual Machine (EVM) and takes the form of a very long list, initially full of zeros. When a contract is compiled, each variable is assigned a <em>slot</em> in the storage following their order in the contract. When data is stored, the EVM picks some of the zeros in the corresponding slots and replace them with the new value.</p>
<p><img src="https://programtheblockchain.com/storage/fixed.png" alt=""></p>
<p><em>Anatomy of a storage slot, from a good <a href="https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/">write-up</a>.</em></p>
<p>When using a proxy, the calls are forwarded to the end/implementation contract, but the data is stored within the proxy itself. To know how to store it, the proxy reads variable from the end contract to define the slots. That means data will be kept when the end contract changes. That also means that if variables changes in the end contract, the storage layout ends up being modified. In certain cases, conflicts in slots can occur, making it impossible for the proxy to find existing slots - or even leading it to erase them.</p>
<p>To prevent this type of conflict in storage from happening, we at Unlock rely on the <a href="https://docs.openzeppelin.com/upgrades/2.8/">Open Zeppelin upgrades library</a> to ensure that storage layout is compatible before proceding to any upgrade.</p>
<h2>Testing upgrades</h2>
<p>Despite avoiding technical failures, we have to make sure to preserve existing features from our contracts during upgrades - and add some new ones! We have an extensive test suite to check that each function does what it is supposed to. However, many features of Unlock relies on external resources, tokens and oracle contracts which is harder to enforce. The complex set of dependencies is hard to recreate locally, so we came up with solutions to tackle it.</p>
<p>First, we developed a set of scripts that are used both for local development and multi-chains deployment. Powered by <a href="https://hardhat.org">hardhat</a>, we now have <a href="https://github.com/unlock-protocol/unlock/tree/master/smart-contracts/scripts">tools</a> to deploy and configure our contracts, submit DAO proposals, upgrade contracts, etc. Before sending an upgade, we run relevant tests on a <a href="https://hardhat.org/hardhat-network/guides/mainnet-forking.html">local fork of Ethereum mainnet</a>, then proceed to an upgrade and finally run the test again against the upgraded version. That way we can check that our contracts behaviours are preserved after an upgrade.</p>
<pre><code class="language-shell">$ yarn hardhat

AVAILABLE TASKS:

  ...
  deploy           	Deploy the entire Unlock protocol
  deploy:governor  	Deploy Governor Alpha contracts
  deploy:oracle    	Deploy UDT &#x3C;> WETH oracle contract
  deploy:template  	Deploy PublicLock contract
  deploy:udt       	Deploy Unlock Discount Token proxy
  deploy:uniswap   	Deploy Uniswap V2 Factory and Router
  deploy:unlock    	Deploy Unlock proxy
  deploy:weth      	Deploy WETH contract
  ...
  gov:delegate     	Delagate voting power
  gov:submit       	Submit a proposal to UDT Governor contract
  gov:vote         	Vote for a proposal on UDT Governor contract
  ...
  impl             	Get the contract implementation address
  ...
  upgrade          	Upgrade an existing contract with a new implementation
  upgrade:prepare  	Deploy the implementation of an upgreadable contract
  upgrade:propose  	Send an upgrade implementation proposal to multisig
  ...
  verify           	Verifies contract on Etherscan
  ...
</code></pre>
<h2>Upgrading contract from another contract</h2>
<p>Besides making our main contracts upgradeable, we started to add the upgrade logic inside our product itself. When you deploy a lock with Unlock, a new instance of the <code>PublicLock</code> contract (ERC-721) is created with the parameters you defined (name, token, etc). In Solidity, several patterns exist to <a href="https://github.com/clemsos/sol-upgrade-pattern/">deploy a contract from another contract</a>. The previous version of Unlock was using a <em>Minimal Proxy</em> (EIP-1167). Instead of deploying the entire contract for each new lock created, a small proxy is deployed just to hold the data and forward calls to a main instance that deals with all the incoming. That allowed to save a non-negligeable amount of gas when deploying a new lock instance.</p>
<p>However, the minimal proxy approach <em>did not allow for upgrades</em>. We wanted all locks to benefit from the latest features available so we started to investigate how we could deploy a full proxy from a contract and <strong>allow users to upgrade their locks</strong> when new features were released. The problem was twofold: 1) allow all managers of a lock to upgrade themselves (keep things decentralized), 2) make sure upgrades are safe.</p>
<p>We used Open Zeppelin <a href="https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.3.0/contracts/proxy/transparent/TransparentUpgradeableProxy.sol">TransparentProxy</a> pattern, and added the following logic to our contract :</p>
<ul>
<li>
<p>when a lock is created:</p>
<ul>
<li>deploy a proxy</li>
<li>point it to the latest implemtation</li>
</ul>
</li>
<li>
<p>when a lock is upgraded:</p>
<ul>
<li>check if the caller is authorized as a lock manager</li>
<li>point to the new implementation</li>
</ul>
</li>
</ul>
<p>We decided to store a single <a href="https://docs.openzeppelin.com/contracts/4.x/api/proxy#ProxyAdmin"><code>ProxyAdmin</code></a> instance in our main contract that will take care of all the upgrade process. When <code>upgradeLock</code> is called, our main contract will check into the deployed lock if the caller is a lock manager. If yes, our proxy admin will proceed to upgrade the lock. If not, the upgrade will be rejected.</p>
<pre><code class="language-solidity">/**
 * @dev Upgrade a Lock template implementation
 * @param lockAddress the address of the lock to be upgraded
 * @param version the version number of the template
 */
function upgradeLock(
  address payable lockAddress,
  uint16 version
) public returns (address) {
  require(proxyAdminAddress != address(0), 'proxyAdmin is not set');

  // check perms
  require(
    _isLockManager(lockAddress, msg.sender) == true,
    'caller is not a manager of this lock'
  );

  // check version
  IPublicLock lock = IPublicLock(lockAddress);
  uint16 currentVersion = lock.publicLockVersion();
  require(
    version == currentVersion + 1,
    'version error: only +1 increments are allowed'
  );

  // make our upgrade
  address impl = _publicLockImpls[version];
  TransparentUpgradeableProxy proxy = TransparentUpgradeableProxy(lockAddress);
  proxyAdmin.upgrade(proxy, impl);

  emit LockUpgraded(lockAddress, version);
  return lockAddress;
}
</code></pre>
<p>The various versions are stored in the contract with a version number and its corresponding implementation. For instance, lock managers can launch an upgrade by calling <code>upgradeLock(0x...lockAddress, 10)</code> to upgrade their lock to version 10 - or through the dashboard. For better compatibility, we forbid bumps of more than one version number (so version 9 to 10 works, but 8 to 10 will fail).</p>
<h2>Coming release</h2>
<p>We are now finalising a new version of the lock template with more features and a few fixes that should come with the upgradeable version! Stay tuned :)</p>



We’re partnering with [Code4rena](https://code423n4.com/), a platform for community-driven smart contract audits, on a 1-week smart contract audit contest starting **today**, November 17th. The contest runs through November 24th, with $50,000 in prizes!

![Code4rena](/images/blog/code4rena-contest/c4-logo.png)

## What is a smart contract audit contest?

Code4rena's contests are not bug bounties — contests have guaranteed payouts for all legit findings.

From Code4rena's site:

**Bug bounties:**

- _Spec work._ No way to have confidence that the time invested will produce a payout.
- _Dark forest._ Who knows how much competition there is right now? Or how mature the codebase is?
- _Grow on your own._ Researchers have to proactively look for ways to learn and level up their skills.
- _Paradox of choice._ So many projects have bounties. How does an auditor choose which to focus on?

vs.

**Audit contests:**

- _Guaranteed payouts._ Auditors know it’s highly likely they can find a bug that will make it worth their time.
- _Low-hanging fruit._ If a project is seeking an audit, it’s likely fresh code with clear opportunities to dig in.
- _Learning community._ Open contests let auditors compare everyone’s findings and learn new things every single week.
- _No FOMO._ C4 runs a handful of active contests at a time—often just one or two, tops.

## Very interesting — how do I participate?

For more on Code4rena and the competition, visit [https://code423n4.com/](https://code423n4.com/)

Join the C4 Discord: [https://discord.gg/9qr6zgbZbj](https://discord.gg/9qr6zgbZbj)


$50,000 in prizes for participants in the Unlock Protocol smart contract code audit contest, launched in conjunction with Code4rena.

Find bugs. Earn money.

Announcing Unlock Protocol's $50,000 Smart Contract Audit Contest

<p>We’re partnering with <a href="https://code423n4.com/">Code4rena</a>, a platform for community-driven smart contract audits, on a 1-week smart contract audit contest starting <strong>today</strong>, November 17th. The contest runs through November 24th, with $50,000 in prizes!</p>
<p><img src="/images/blog/code4rena-contest/c4-logo.png" alt="Code4rena"></p>
<h2>What is a smart contract audit contest?</h2>
<p>Code4rena's contests are not bug bounties — contests have guaranteed payouts for all legit findings.</p>
<p>From Code4rena's site:</p>
<p><strong>Bug bounties:</strong></p>
<ul>
<li><em>Spec work.</em> No way to have confidence that the time invested will produce a payout.</li>
<li><em>Dark forest.</em> Who knows how much competition there is right now? Or how mature the codebase is?</li>
<li><em>Grow on your own.</em> Researchers have to proactively look for ways to learn and level up their skills.</li>
<li><em>Paradox of choice.</em> So many projects have bounties. How does an auditor choose which to focus on?</li>
</ul>
<p>vs.</p>
<p><strong>Audit contests:</strong></p>
<ul>
<li><em>Guaranteed payouts.</em> Auditors know it’s highly likely they can find a bug that will make it worth their time.</li>
<li><em>Low-hanging fruit.</em> If a project is seeking an audit, it’s likely fresh code with clear opportunities to dig in.</li>
<li><em>Learning community.</em> Open contests let auditors compare everyone’s findings and learn new things every single week.</li>
<li><em>No FOMO.</em> C4 runs a handful of active contests at a time—often just one or two, tops.</li>
</ul>
<h2>Very interesting — how do I participate?</h2>
<p>For more on Code4rena and the competition, visit <a href="https://code423n4.com/">https://code423n4.com/</a></p>
<p>Join the C4 Discord: <a href="https://discord.gg/9qr6zgbZbj">https://discord.gg/9qr6zgbZbj</a></p>



Cohort 4 of the Unlock Grantees are here and ready to push the protocol towards wider adoption by those who need it most! Cohort 4 covers everything from removing barriers to crypto entry for SaaS providers, to integrating with Element, making DAO participation more equitable for all — and so much more!

![Cohort 4](/images/blog/cohort-4/cohort-4.png)

Check out these brief introductions for each grantee, their project and how to find them on the Twitters so you can follow their progress. If reading about these projects sparks your creation engine, simply click the link at the bottom of the article and submit your proposal to join the next cohort! Our grant selection committee will be meeting soon to review the latest applications— so don't wait!

## David Layton - Unfurl

[https://www.linkedin.com/in/david-matthew-layton](https://www.linkedin.com/in/david-matthew-layton)

David Layton is creating Unfurl, an Open ID Connect Provider powered by Unlock Protocol. His goal is to make entry to cryptocurrency subscriptions as easy as possible for SaaS providers. He also successfully lead the Firebase integration of Unlock. Removing the friction for SaaS' entering the crypto space is a huge step towards mass adoption of web3 technology (and our protocol too)!

## MJ Zilla - Element Integration

[https://twitter.com/\_mecyver](https://twitter.com/_mecyver)

MJ, aka Mecyver is working on an Element + Unlock integration. Providing a viable alternative to community building outside of Discord that utilizes our protocol to manage memberships will help support more adoption by creators! We're very excited to see a fresh integration for private and group chats that is also open-source and encrypted.

## Stephen Grinalds - Chisos Capital

[https://twitter.com/ChisosCapital](https://twitter.com/ChisosCapital)

Chisos Capital is utilizing Unlock to support their membership club and community of investors and entrepreneurs throughout their ecosystem.

## Carlos Diaz-Padron and Gail Wilson - Metaphor

[https://twitter.com/the_carlosdp](https://twitter.com/the_carlosdp)

Carlos and Gail are working on an integration for Metaphor's DAO onboarding tool, with the intention of creating an easy method for joining a DAO. This will allow members to bypass expensive, and often prohibitive, token ownership that normally powers DAO participation.

## Fanny Lakoubay - BAD 2.0 (Blockchain Art Directory)

[https://twitter.com/badOG_xyz](https://twitter.com/badOG_xyz)

Fanny is looking to incorporate Unlock into the existing BAD platform to help them elevate their mission and further embrace the full power of web3. BAD was originally built in 2017 to help serve as a directory for blockchain art. BAD is upping their game to better serve the blockchain art community which is hot right now!

### Are you ready to join our Grantees?

We’re excited to have such fabulous projects in our grant program and are wishing our grantees all the best as they bring their visions to life. If you’d like to join our Discord to connect with our grantees about their projects or explore some ideas of your own, please [join us here](https://discord.gg/Ah6ZEJyTDp).

AND if you already have an idea for an integration using Unlock, please submit your project [proposal here](https://share.hsforms.com/1gAdLgNOESNCWJ9bJxCUAMwbvg22).

Unlock Protocol is driven by and for our community. We’re here to help YOU build the future path of blockchain technology and together we’ll explore all that’s possible with community and decentralization as our core foundations. [Join the conversation](https://unlock.community/).


Unlock Grantees Cohort 4 covers everything from easy crypto adoption for SaaS to Element integrations and everything in between!

A web3 Discord alternative, memberships, DAO onboarding, and identity!

Let's celebrate our 4th Cohort of Unlock Grantees

<p>Cohort 4 of the Unlock Grantees are here and ready to push the protocol towards wider adoption by those who need it most! Cohort 4 covers everything from removing barriers to crypto entry for SaaS providers, to integrating with Element, making DAO participation more equitable for all — and so much more!</p>
<p><img src="/images/blog/cohort-4/cohort-4.png" alt="Cohort 4"></p>
<p>Check out these brief introductions for each grantee, their project and how to find them on the Twitters so you can follow their progress. If reading about these projects sparks your creation engine, simply click the link at the bottom of the article and submit your proposal to join the next cohort! Our grant selection committee will be meeting soon to review the latest applications— so don't wait!</p>
<h2>David Layton - Unfurl</h2>
<p><a href="https://www.linkedin.com/in/david-matthew-layton">https://www.linkedin.com/in/david-matthew-layton</a></p>
<p>David Layton is creating Unfurl, an Open ID Connect Provider powered by Unlock Protocol. His goal is to make entry to cryptocurrency subscriptions as easy as possible for SaaS providers. He also successfully lead the Firebase integration of Unlock. Removing the friction for SaaS' entering the crypto space is a huge step towards mass adoption of web3 technology (and our protocol too)!</p>
<h2>MJ Zilla - Element Integration</h2>
<p><a href="https://twitter.com/_mecyver">https://twitter.com/_mecyver</a></p>
<p>MJ, aka Mecyver is working on an Element + Unlock integration. Providing a viable alternative to community building outside of Discord that utilizes our protocol to manage memberships will help support more adoption by creators! We're very excited to see a fresh integration for private and group chats that is also open-source and encrypted.</p>
<h2>Stephen Grinalds - Chisos Capital</h2>
<p><a href="https://twitter.com/ChisosCapital">https://twitter.com/ChisosCapital</a></p>
<p>Chisos Capital is utilizing Unlock to support their membership club and community of investors and entrepreneurs throughout their ecosystem.</p>
<h2>Carlos Diaz-Padron and Gail Wilson - Metaphor</h2>
<p><a href="https://twitter.com/the_carlosdp">https://twitter.com/the_carlosdp</a></p>
<p>Carlos and Gail are working on an integration for Metaphor's DAO onboarding tool, with the intention of creating an easy method for joining a DAO. This will allow members to bypass expensive, and often prohibitive, token ownership that normally powers DAO participation.</p>
<h2>Fanny Lakoubay - BAD 2.0 (Blockchain Art Directory)</h2>
<p><a href="https://twitter.com/badOG_xyz">https://twitter.com/badOG_xyz</a></p>
<p>Fanny is looking to incorporate Unlock into the existing BAD platform to help them elevate their mission and further embrace the full power of web3. BAD was originally built in 2017 to help serve as a directory for blockchain art. BAD is upping their game to better serve the blockchain art community which is hot right now!</p>
<h3>Are you ready to join our Grantees?</h3>
<p>We’re excited to have such fabulous projects in our grant program and are wishing our grantees all the best as they bring their visions to life. If you’d like to join our Discord to connect with our grantees about their projects or explore some ideas of your own, please <a href="https://discord.gg/Ah6ZEJyTDp">join us here</a>.</p>
<p>AND if you already have an idea for an integration using Unlock, please submit your project <a href="https://share.hsforms.com/1gAdLgNOESNCWJ9bJxCUAMwbvg22">proposal here</a>.</p>
<p>Unlock Protocol is driven by and for our community. We’re here to help YOU build the future path of blockchain technology and together we’ll explore all that’s possible with community and decentralization as our core foundations. <a href="https://unlock.community/">Join the conversation</a>.</p>



Until today, Unlock was available [on xDAI](/blog/xdai), [Polygon](/blog/unlock-on-polygon) and, of course, Ethereum's mainnet. Today, we're announcing that creators can now easily deploy Unlock on the [Binance Smart Chain](https://www.binance.org/en/smartChain).

Our strategy is to let creators chose where in the EVM ecosystem they want to deploy their locks. Some will choose the mainnet for its higher level of trustlessness, and are willing to bear the cost of high gas prices, while others are fine using cheaper chains. As such, we will be _everywhere_ that the EVM goes.

On BSC, gas is paid in BNB, and memberships can be priced in BNB, or, like on other chains, in any ERC20.

![Binance Smart Chain](/images/blog/bsc.png)

Want to purchase membership on BSC? [try this one](https://app.unlock-protocol.com/demo?network=56&lock=0x2B0fba627C0145B86a9e33c36cFF3a8592CF36d6)! Gas costs are within the $0.50 range. You can also easily deploy a lock from your dashboard, by making sure you select the Binance Smart Chain network.

For now, [contrary to xDAI and Polygon](https://docs.unlock-protocol.com/governance/the-unlock-token/side-chains-and-layer-2), purchases on BSC will **not** yield UDT, but we're keeping this as an option if we start to see significant usage on that network!


Some of our community members have asked for Unlock to be deeployed on BSC. This is now shipped.

Unlock is now available on the Binance Smart Chain!

Binance Smart Chain

<p>Until today, Unlock was available <a href="/blog/xdai">on xDAI</a>, <a href="/blog/unlock-on-polygon">Polygon</a> and, of course, Ethereum's mainnet. Today, we're announcing that creators can now easily deploy Unlock on the <a href="https://www.binance.org/en/smartChain">Binance Smart Chain</a>.</p>
<p>Our strategy is to let creators chose where in the EVM ecosystem they want to deploy their locks. Some will choose the mainnet for its higher level of trustlessness, and are willing to bear the cost of high gas prices, while others are fine using cheaper chains. As such, we will be <em>everywhere</em> that the EVM goes.</p>
<p>On BSC, gas is paid in BNB, and memberships can be priced in BNB, or, like on other chains, in any ERC20.</p>
<p><img src="/images/blog/bsc.png" alt="Binance Smart Chain"></p>
<p>Want to purchase membership on BSC? <a href="https://app.unlock-protocol.com/demo?network=56&#x26;lock=0x2B0fba627C0145B86a9e33c36cFF3a8592CF36d6">try this one</a>! Gas costs are within the $0.50 range. You can also easily deploy a lock from your dashboard, by making sure you select the Binance Smart Chain network.</p>
<p>For now, <a href="https://docs.unlock-protocol.com/governance/the-unlock-token/side-chains-and-layer-2">contrary to xDAI and Polygon</a>, purchases on BSC will <strong>not</strong> yield UDT, but we're keeping this as an option if we start to see significant usage on that network!</p>



![How communities and clubs can use Unlock](/images/blog/tokenized-memberships.jpg)

Unlock can be a tool to create unique memberships for nearly any kind of member-based organization - from recognizing membership in a cooperative, to being an access pass for a social club, to being an organizing tool for a book club or investment DAO, there are several ways that Unlock Protocol can be leveraged.

## How this works

One way that membership-based organizations can use Unlock is by recognizing membership with a particular lock that is used as a membership badge to give member benefits.

## Example: Dinner DAO

[Dinner DAO](https://mmm.page/dinnerdao.main) is a club for organizing monthly social dinners in NYC. This was done using Unlock Protocol by creating NFTs to represent membership in the club. In this example, 8 passes were available for purchase for .1 ETH each -- giving each owner the ability to access a private Discord, and a [Snapshot](https://snapshot.org/#/dinnerdao.eth) for creating and voting on proposals.

As an example, here’s the tech stack used and how Unlock enabled the Dinner DAO.

### Creating locks

First, through the Unlock Creator Dashboard, 8 Locks were created that represented a membership in Season 1 of the Dinner DAO. The duration of the lock was set to match this time frame.

### Website with purchase link

Next, a simple webpage linked out to the Purchase Address link which allowed users to purchase the NFT pass.
Once someone purchased the NFT pass, they were redirected to the Dinner DAO Discord, where they were instructed to connect to [Collab.Land](https://docs.unlock-protocol.com/move-to-guides/plugins-and-integrations/collab-land) to verify their membership, which allowed them to join a private channel.

### Voting for members

Then, a Snapshot was set up that allowed for members with the Unlock NFT pass to create and vote on proposals. For information on how to set up voting with Snapshot, you can read more about it in the documentation here.

### Special access for members

In this example, Dinner DAO members have special access to both voting on Snapshot and to a private Discord channel. However, using other integrations, we could continue to build out more content and online spaces that only members with the NFT pass have access to.

## Other opportunities

This is one example of many for how Unlock could be used to organize collective groups, clubs, and communities. How you use Unlocks features and integrations could be completely customizable to fit the needs of many different organizations, including but not limited to:

- DAOs
- Private online groups
- Social clubs
- Book clubs
- And more


Unlock can be a tool to create unique memberships for nearly any kind of member-based organization - from recognizing membership in a cooperative, to being an access pass for a social club, to being an organizing tool for a book club or investment DAO, there are several ways that Unlock Protocol can be leveraged.

Unlock can be a tool to create unique memberships for nearly any kind of member-based organization

How communities and clubs can use Unlock

<p><img src="/images/blog/tokenized-memberships.jpg" alt="How communities and clubs can use Unlock"></p>
<p>Unlock can be a tool to create unique memberships for nearly any kind of member-based organization - from recognizing membership in a cooperative, to being an access pass for a social club, to being an organizing tool for a book club or investment DAO, there are several ways that Unlock Protocol can be leveraged.</p>
<h2>How this works</h2>
<p>One way that membership-based organizations can use Unlock is by recognizing membership with a particular lock that is used as a membership badge to give member benefits.</p>
<h2>Example: Dinner DAO</h2>
<p><a href="https://mmm.page/dinnerdao.main">Dinner DAO</a> is a club for organizing monthly social dinners in NYC. This was done using Unlock Protocol by creating NFTs to represent membership in the club. In this example, 8 passes were available for purchase for .1 ETH each -- giving each owner the ability to access a private Discord, and a <a href="https://snapshot.org/#/dinnerdao.eth">Snapshot</a> for creating and voting on proposals.</p>
<p>As an example, here’s the tech stack used and how Unlock enabled the Dinner DAO.</p>
<h3>Creating locks</h3>
<p>First, through the Unlock Creator Dashboard, 8 Locks were created that represented a membership in Season 1 of the Dinner DAO. The duration of the lock was set to match this time frame.</p>
<h3>Website with purchase link</h3>
<p>Next, a simple webpage linked out to the Purchase Address link which allowed users to purchase the NFT pass.
Once someone purchased the NFT pass, they were redirected to the Dinner DAO Discord, where they were instructed to connect to <a href="https://docs.unlock-protocol.com/move-to-guides/plugins-and-integrations/collab-land">Collab.Land</a> to verify their membership, which allowed them to join a private channel.</p>
<h3>Voting for members</h3>
<p>Then, a Snapshot was set up that allowed for members with the Unlock NFT pass to create and vote on proposals. For information on how to set up voting with Snapshot, you can read more about it in the documentation here.</p>
<h3>Special access for members</h3>
<p>In this example, Dinner DAO members have special access to both voting on Snapshot and to a private Discord channel. However, using other integrations, we could continue to build out more content and online spaces that only members with the NFT pass have access to.</p>
<h2>Other opportunities</h2>
<p>This is one example of many for how Unlock could be used to organize collective groups, clubs, and communities. How you use Unlocks features and integrations could be completely customizable to fit the needs of many different organizations, including but not limited to:</p>
<ul>
<li>DAOs</li>
<li>Private online groups</li>
<li>Social clubs</li>
<li>Book clubs</li>
<li>And more</li>
</ul>



Chroma Signet uses blockchain-based solutions to provide supply chain transparency and provenance across the entire consumer packaged goods (CPG) industry. When brands want to share seed-to-sale supply chain data, in-depth ingredient details, or their brand story with customers, they choose Chroma Signet.

When Chroma Signet wanted to enhance their offering and additionally offer a digital twin for every instance of every product in the supply chain in the form of an NFT, they went searching for a solution and found their answer in the Unlock Protocol.

[See the full case study](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/Chroma%20Signet%20-%20Unlock%20Case%20Study.pdf).

[![Chroma Signet thumbnail](/images/blog/chroma-signet-unlock-case-study/chroma-signet-thumbnail-2.png)](https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/Chroma%20Signet%20-%20Unlock%20Case%20Study.pdf)


Chroma Signet uses Unlock Protocol and cuts six months off the dev time required to create NFT-based digital twins for every instance of every product in the supply chain.

Lightspeed creation of NFT-based digital twins for every instance of every product in the supply chain

Chroma Signet Cuts Dev Time By 6 Months | Unlock Case Study

<p>Chroma Signet uses blockchain-based solutions to provide supply chain transparency and provenance across the entire consumer packaged goods (CPG) industry. When brands want to share seed-to-sale supply chain data, in-depth ingredient details, or their brand story with customers, they choose Chroma Signet.</p>
<p>When Chroma Signet wanted to enhance their offering and additionally offer a digital twin for every instance of every product in the supply chain in the form of an NFT, they went searching for a solution and found their answer in the Unlock Protocol.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/Chroma%20Signet%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.</p>
<p><a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/Chroma%20Signet%20-%20Unlock%20Case%20Study.pdf"><img src="/images/blog/chroma-signet-unlock-case-study/chroma-signet-thumbnail-2.png" alt="Chroma Signet thumbnail"></a></p>
