
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>



Hello, Unlock community! We’re very excited to announce that [Austin Robey](https://twitter.com/austinrobey_) is now Unlock’s Head of Growth. He’ll help us expand the use of our protocol within the indie music industry and beyond. Co-founder of [Ampled](https://twitter.com/ampl3d), a co-op support platform for musicians that’s among the first orgs to integrate Unlock, Austin is a recent recipient in our Token Grant program, and the founder of the fast-growing [Dinner DAO](https://unlock-protocol.com/blog/dinnerdao), along with being an active member of several DAOs, such as Seed Club and Forefront. Last month he wrote [a post on our blog](https://unlock-protocol.com/blog/how-musicians-can-use-unlock) detailing the many ways musicians can leverage Unlock to grow and maintain their fanbase.

![Amber Case](/images/blog/austin-robey.png)

I first met Austin in my work as a Fellow studying web monetization with the [Mozilla Foundation](https://www.mozilla.org/en-US/). Since then he’s dived into Web3 technologies with impressive energy and passion to help Unlock work for independent creators. We also love his strong design background, with an architecture degree from Pratt, and an ongoing relationship as a designer with the New Museum of Contemporary Art in New York. So we can’t wait to see how he better connects Unlock with projects across many creative fields.

What that let me turn the mic over to Austin to talk about his new role, and his vision for helping Unlock:

> I’m excited to begin work as Unlock Protocol’s Head of Growth.

> In my previous work (as a founder of [Ampled](http://www.ampled.com/), and also as a DAO member of groups like [Forefront](https://forefront.market/) and [Seed Club](https://seedclub.xyz/)) I’ve been passionate about exploring alternative economic structures to support creators. Unlock, in particular, is incredibly powerful tooling that I believe can help generate a new foundation for a creator-first online economy.

> I see Web 3.0 as a new paradigm that can shift power away from platforms and back towards people. I’ve been impressed by the Unlock team and their foresight and commitment towards the creation of a more distributed, equitable, and open web.

> Unlock’s forward-thinking approach to NFTs is unique. While many people currently associate NFTs with pixelated crypto art,  Unlock is demonstrating that NFTs can be much more. Not only can an NFT represent artwork, but it can also be a membership badge, access pass, or passport to participate in digital (or physical) experiences across the web or IRL. This has the potential to radically reshape our entire creative economy away from attention and advertisements - and help us create new business models -- free from corporate walled gardens and monopolistic tech platforms.

> We’re still in the very early stages of a new Web 3.0 era for creators and communities. In my role, I’ll be helping tell the story of Unlock, its capabilities, and onboarding great communities to showcase the transformative power of the protocol.

> If you’d like to connect, I’d love to hear what you are working on. Feel free to reach me at [austin@unlock-protocol.com](mailto:austin@unlock-protocol.com) or in the [Unlock Discord](https://discord.gg/N5y68jAvKF).

Also, 👋 if you’re in the Oregon area, come say Hi to Austin and I at [Eth Portland 2021](https://2021.ethportland.com/).


We’re very excited to announce that Austin Robey is now Unlock’s Head of Growth! He’ll help us expand the use of our protocol within the indie music industry and beyond

Growing the team, to grow usage of the protocol!

Welcome Austin Robey to Unlock!

<p>Hello, Unlock community! We’re very excited to announce that <a href="https://twitter.com/austinrobey_">Austin Robey</a> is now Unlock’s Head of Growth. He’ll help us expand the use of our protocol within the indie music industry and beyond. Co-founder of <a href="https://twitter.com/ampl3d">Ampled</a>, a co-op support platform for musicians that’s among the first orgs to integrate Unlock, Austin is a recent recipient in our Token Grant program, and the founder of the fast-growing <a href="https://unlock-protocol.com/blog/dinnerdao">Dinner DAO</a>, along with being an active member of several DAOs, such as Seed Club and Forefront. Last month he wrote <a href="https://unlock-protocol.com/blog/how-musicians-can-use-unlock">a post on our blog</a> detailing the many ways musicians can leverage Unlock to grow and maintain their fanbase.</p>
<p><img src="/images/blog/austin-robey.png" alt="Amber Case"></p>
<p>I first met Austin in my work as a Fellow studying web monetization with the <a href="https://www.mozilla.org/en-US/">Mozilla Foundation</a>. Since then he’s dived into Web3 technologies with impressive energy and passion to help Unlock work for independent creators. We also love his strong design background, with an architecture degree from Pratt, and an ongoing relationship as a designer with the New Museum of Contemporary Art in New York. So we can’t wait to see how he better connects Unlock with projects across many creative fields.</p>
<p>What that let me turn the mic over to Austin to talk about his new role, and his vision for helping Unlock:</p>
<blockquote>
<p>I’m excited to begin work as Unlock Protocol’s Head of Growth.</p>
</blockquote>
<blockquote>
<p>In my previous work (as a founder of <a href="http://www.ampled.com/">Ampled</a>, and also as a DAO member of groups like <a href="https://forefront.market/">Forefront</a> and <a href="https://seedclub.xyz/">Seed Club</a>) I’ve been passionate about exploring alternative economic structures to support creators. Unlock, in particular, is incredibly powerful tooling that I believe can help generate a new foundation for a creator-first online economy.</p>
</blockquote>
<blockquote>
<p>I see Web 3.0 as a new paradigm that can shift power away from platforms and back towards people. I’ve been impressed by the Unlock team and their foresight and commitment towards the creation of a more distributed, equitable, and open web.</p>
</blockquote>
<blockquote>
<p>Unlock’s forward-thinking approach to NFTs is unique. While many people currently associate NFTs with pixelated crypto art,  Unlock is demonstrating that NFTs can be much more. Not only can an NFT represent artwork, but it can also be a membership badge, access pass, or passport to participate in digital (or physical) experiences across the web or IRL. This has the potential to radically reshape our entire creative economy away from attention and advertisements - and help us create new business models -- free from corporate walled gardens and monopolistic tech platforms.</p>
</blockquote>
<blockquote>
<p>We’re still in the very early stages of a new Web 3.0 era for creators and communities. In my role, I’ll be helping tell the story of Unlock, its capabilities, and onboarding great communities to showcase the transformative power of the protocol.</p>
</blockquote>
<blockquote>
<p>If you’d like to connect, I’d love to hear what you are working on. Feel free to reach me at <a href="mailto:austin@unlock-protocol.com">austin@unlock-protocol.com</a> or in the <a href="https://discord.gg/N5y68jAvKF">Unlock Discord</a>.</p>
</blockquote>
<p>Also, 👋 if you’re in the Oregon area, come say Hi to Austin and I at <a href="https://2021.ethportland.com/">Eth Portland 2021</a>.</p>



While working on debugging a signature issue in the UDT contract, we identified a critical vulnerability. This vulnerability was introduced in a UDT contract upgrade on August 2nd 2021 and discovered on October 14th around 1045AM ET. A patch was successfully deployed on [the same day at about 1PM ET](https://etherscan.io/tx/0x615f52d89673d41e7c5d3940beb50d586331f4664bae69556ef70b877175896c). The vulnerability was *not* exploited.

# The vulnerability

In a nutshell, the vulnerability *allowed anyone to burn tokens from any other address.* Even though this could not have resulted in funds being transferred, and we could have recovered any "burned" tokens through a contract upgrade, we believe it could have impacted the price and behavior of the protocol in ways that would have been hard to recover from.

The UDT contract did not originally included a `burn` function. However, in order to support [governance](https://unlock-protocol.com/blog/unlock-dao) functions, we had to perform an upgrade to our contract on August 2nd 2021. Even though we only used [OpenZeppelin](https://openzeppelin.com/contracts/)'s library for the UDT contract (and did not write any logic ourselves), the upgrade required some very specific work to support changes in the contract storage between the version we deployed in November 2020 and the ERC20 version used for governance. Specifically, we had to flatten the OpenZeppelin library in order to apply some patches to avoid storage slot conflicts.

While doing, so we overlooked that we had to remove the `burn` function from the flattened contract file.

# The patch

Fixing the vulnerability was trivial: we just rendered the `burn` function non operating by removing the internal call to `_burn`. In a subsequent deployment, we completely removed the `burn` function so that calling it will result in errors.

# Signatures

We identified the vulnerability as we were debugging some signature issues. We had previously found that a lot of the delegations performed using the `delegateBySig` function did not effectively perform delegation as we expected. We found that the contract was *recovering* a signer address that did not match the actual signer on the front-end. The team at OpenZeppelin kindly helped us identify the issue, where we realized that when we performed that August 2nd update, we failed to call some required initializers (namely, `EIP712_init`, `ERC20Permit_init` and `ERC20Votes_init`). Not calling these lead to the signatures being computed in an unexpected way.

Our patch was thoroughly tested, but it was never tested *as an upgrade*, but rather as a whole new implementation/deployment. This is the root cause of the issues we were seeing.

# Moving forward

Even though the vulnerability was **not** exploited, we have put ourselves and all of the people who are governing the protocol *at risk*. This is not something we take lightly and we will have to perform a few important changes.

- We will add a new testing framework to test our changes *as upgrades* (on top of unit tests). We already leverage hardhat's amazing "local fork" feature and we will increase our use of this. We will additionally perform these tests as part of our CI cycle.
- We will perform an audit for the UDT contract. We have always considered, and this is still the case, that the funds at risk on the Unlock and PublicLock contracts (the core protocol) were in fact smaller than the cost of auditing (especially as the protocol still evolves quickly). However, this is not the case for the UDT contract. We have contacted a few firms and we will share results once we have them.
- Even though no funds were stolen, the signature issue we identified means that a lot of people who have claimed tokens for the airdrop did not actually delegate their votes. We have identified the list of all accounts that have been affected. We are pondering a way to cover the gas cost of them issuing a 2nd delegation and we'll have something to offer soon.

In closing, I want to offer a very special thank you to Hadrien and Francisco at OpenZeppelin who have been extremely helpful along the way.


While working on debugging a signature issue in the UDT contract, we identified a critical vulnerability. This vulnerability was introduced in a UDT contract upgrade on August 2nd 2021 and discovered on October 14th around 1045AM ET. A patch was successfully deployed on the same day at about 1PM ET. The vulnerability was not exploited.

Last week, we identified a serious vulnerability in the UDT contract. It is now fixed and has not been exploited.

UDT Vulnerability Disclosure

<p>While working on debugging a signature issue in the UDT contract, we identified a critical vulnerability. This vulnerability was introduced in a UDT contract upgrade on August 2nd 2021 and discovered on October 14th around 1045AM ET. A patch was successfully deployed on <a href="https://etherscan.io/tx/0x615f52d89673d41e7c5d3940beb50d586331f4664bae69556ef70b877175896c">the same day at about 1PM ET</a>. The vulnerability was <em>not</em> exploited.</p>
<h1>The vulnerability</h1>
<p>In a nutshell, the vulnerability <em>allowed anyone to burn tokens from any other address.</em> Even though this could not have resulted in funds being transferred, and we could have recovered any "burned" tokens through a contract upgrade, we believe it could have impacted the price and behavior of the protocol in ways that would have been hard to recover from.</p>
<p>The UDT contract did not originally included a <code>burn</code> function. However, in order to support <a href="https://unlock-protocol.com/blog/unlock-dao">governance</a> functions, we had to perform an upgrade to our contract on August 2nd 2021. Even though we only used <a href="https://openzeppelin.com/contracts/">OpenZeppelin</a>'s library for the UDT contract (and did not write any logic ourselves), the upgrade required some very specific work to support changes in the contract storage between the version we deployed in November 2020 and the ERC20 version used for governance. Specifically, we had to flatten the OpenZeppelin library in order to apply some patches to avoid storage slot conflicts.</p>
<p>While doing, so we overlooked that we had to remove the <code>burn</code> function from the flattened contract file.</p>
<h1>The patch</h1>
<p>Fixing the vulnerability was trivial: we just rendered the <code>burn</code> function non operating by removing the internal call to <code>_burn</code>. In a subsequent deployment, we completely removed the <code>burn</code> function so that calling it will result in errors.</p>
<h1>Signatures</h1>
<p>We identified the vulnerability as we were debugging some signature issues. We had previously found that a lot of the delegations performed using the <code>delegateBySig</code> function did not effectively perform delegation as we expected. We found that the contract was <em>recovering</em> a signer address that did not match the actual signer on the front-end. The team at OpenZeppelin kindly helped us identify the issue, where we realized that when we performed that August 2nd update, we failed to call some required initializers (namely, <code>EIP712_init</code>, <code>ERC20Permit_init</code> and <code>ERC20Votes_init</code>). Not calling these lead to the signatures being computed in an unexpected way.</p>
<p>Our patch was thoroughly tested, but it was never tested <em>as an upgrade</em>, but rather as a whole new implementation/deployment. This is the root cause of the issues we were seeing.</p>
<h1>Moving forward</h1>
<p>Even though the vulnerability was <strong>not</strong> exploited, we have put ourselves and all of the people who are governing the protocol <em>at risk</em>. This is not something we take lightly and we will have to perform a few important changes.</p>
<ul>
<li>We will add a new testing framework to test our changes <em>as upgrades</em> (on top of unit tests). We already leverage hardhat's amazing "local fork" feature and we will increase our use of this. We will additionally perform these tests as part of our CI cycle.</li>
<li>We will perform an audit for the UDT contract. We have always considered, and this is still the case, that the funds at risk on the Unlock and PublicLock contracts (the core protocol) were in fact smaller than the cost of auditing (especially as the protocol still evolves quickly). However, this is not the case for the UDT contract. We have contacted a few firms and we will share results once we have them.</li>
<li>Even though no funds were stolen, the signature issue we identified means that a lot of people who have claimed tokens for the airdrop did not actually delegate their votes. We have identified the list of all accounts that have been affected. We are pondering a way to cover the gas cost of them issuing a 2nd delegation and we'll have something to offer soon.</li>
</ul>
<p>In closing, I want to offer a very special thank you to Hadrien and Francisco at OpenZeppelin who have been extremely helpful along the way.</p>



We’re so excited to announce the third cohort of grantees for the Unlock Protocol grant program! Our grant selection committee met at the beginning of September and selected a fabulous range of projects. From Notion integrations, creator portals, DAO support tools, lending protocols and more! The scope of these projects shows us all what’s possible with a little creativity and ingenuity.

![Cohort 3](/images/blog/cohort-3/grant-program-sept-2021.png)

Here’s a quick introduction to 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!

## Matt Mankins - Notion

[https://www.twitter.com/mankins](https://www.twitter.com/mankins)

Matt will be working on an Unlock integration for Notion pages. We love us some Notion and are excited to see this come to life!

## Yuriy Dybskiy - Puma Browser

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

Puma is a mobile browser and wallet for the Web3 ecosystem and is focusing on creating support for lock detection and the ability to unlock/get a key natively in the app. The Puma team started this project as part of the HackFS Hackathon and is continuing this project with our grant program.

## Patrick Murphy - Aloy

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

Aloy’s working to create better loyalty programs through digital assets. They are building a SaaS solution that allows brands in the travel, hospitality, and leisure sector to create NFT-enabled membership programs that tie real-world benefits to the ownership of digital assets (NFTs).

## Josh - The Blockchain Socialist

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

The Blockchain Socialist is a blog and podcast that explores the intersection of blockchain and left politics. Josh will be exploring deeper ways of integrating Unlock to try and create a true web3 version of Patreon.

## Victor Feng - Nama Protocol

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

Nama Protocol is a multi-chain enabled lending protocol that empowers borrowers to use their NFTs as collateral to get loans and lenders to stake their stablecoins to the lending pools to get high yield farming and gain attractive interest while lending to borrowers. Nama Protocol will be using Unlock in various aspect of their protocol.

## Jess Sloss - Seed Club

[www.twitter.com/seedclubhq](http://www.twitter.com/seedclubhq)

Seed Club is a DAO that builds and invests in communities with tokens. They're actively working with the Unlock protocol to better define the use cases we see emerging with the hope that Unlock can be a core tool to power the Seed Club.

## Pedro Alves - Creator Portal

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

Dev Protocol is building a Creators Portal using Unlock to help support patrons using their robust platform. Dev Protocol is working to build a Decentralized Creator Economy and creator DAOs to support the web3 movement.

# Are you ready to join our Grantees?

We’re excited to have such insightful 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/).


We're so excited to announce our third cohort of Unlock grantees! Please check out their projects and follow their progress!

More brilliant minds are bringing some amazing Unlock integrations to life!

A big welcome to our cohort 3 grantees

<p>We’re so excited to announce the third cohort of grantees for the Unlock Protocol grant program! Our grant selection committee met at the beginning of September and selected a fabulous range of projects. From Notion integrations, creator portals, DAO support tools, lending protocols and more! The scope of these projects shows us all what’s possible with a little creativity and ingenuity.</p>
<p><img src="/images/blog/cohort-3/grant-program-sept-2021.png" alt="Cohort 3"></p>
<p>Here’s a quick introduction to 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!</p>
<h2>Matt Mankins - Notion</h2>
<p><a href="https://www.twitter.com/mankins">https://www.twitter.com/mankins</a></p>
<p>Matt will be working on an Unlock integration for Notion pages. We love us some Notion and are excited to see this come to life!</p>
<h2>Yuriy Dybskiy - Puma Browser</h2>
<p><a href="https://twitter.com/pumabrowser">https://twitter.com/pumabrowser</a></p>
<p>Puma is a mobile browser and wallet for the Web3 ecosystem and is focusing on creating support for lock detection and the ability to unlock/get a key natively in the app. The Puma team started this project as part of the HackFS Hackathon and is continuing this project with our grant program.</p>
<h2>Patrick Murphy - Aloy</h2>
<p><a href="https://twitter.com/aloy_club">https://twitter.com/aloy_club</a></p>
<p>Aloy’s working to create better loyalty programs through digital assets. They are building a SaaS solution that allows brands in the travel, hospitality, and leisure sector to create NFT-enabled membership programs that tie real-world benefits to the ownership of digital assets (NFTs).</p>
<h2>Josh - The Blockchain Socialist</h2>
<p><a href="https://twitter.com/TBSocialist">https://twitter.com/TBSocialist</a></p>
<p>The Blockchain Socialist is a blog and podcast that explores the intersection of blockchain and left politics. Josh will be exploring deeper ways of integrating Unlock to try and create a true web3 version of Patreon.</p>
<h2>Victor Feng - Nama Protocol</h2>
<p><a href="https://twitter.com/nama_finance">https://twitter.com/nama_finance</a></p>
<p>Nama Protocol is a multi-chain enabled lending protocol that empowers borrowers to use their NFTs as collateral to get loans and lenders to stake their stablecoins to the lending pools to get high yield farming and gain attractive interest while lending to borrowers. Nama Protocol will be using Unlock in various aspect of their protocol.</p>
<h2>Jess Sloss - Seed Club</h2>
<p><a href="http://www.twitter.com/seedclubhq">www.twitter.com/seedclubhq</a></p>
<p>Seed Club is a DAO that builds and invests in communities with tokens. They're actively working with the Unlock protocol to better define the use cases we see emerging with the hope that Unlock can be a core tool to power the Seed Club.</p>
<h2>Pedro Alves - Creator Portal</h2>
<p><a href="https://twitter.com/devprtcl">https://twitter.com/devprtcl</a></p>
<p>Dev Protocol is building a Creators Portal using Unlock to help support patrons using their robust platform. Dev Protocol is working to build a Decentralized Creator Economy and creator DAOs to support the web3 movement.</p>
<h1>Are you ready to join our Grantees?</h1>
<p>We’re excited to have such insightful 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>



Last week, we introduced the [Unlock DAO](/blog/unlock-dao) where anyone can contribute proposals and vote on these in order to collectively govern the protocol and its treasury. Today, we're excited to announce that we're going one step further by doing a **retro-active airdrop**: anyone who has contributed to Unlock before September 1st 2021 is eligible to receive some ɄDT.

We expect to distribute **up to 7,314 ɄDT**! Claim your tokens now at [https://airdrop.unlock-protocol.com/](https://airdrop.unlock-protocol.com/)

<p style="
    text-align: center;
"><img src="/images/blog/airdrop/coin.png" alt="Unlock DAO"></p>

# Rewarding past contributions

The protocol already [mints and distributes](https://docs.unlock-protocol.com/governance/the-unlock-token) new tokens for every eligible key purchase. This very important mechanims lets us make sure that developers, creators and members who participate in the network's growth get a say in its governance.

However, we introduced the tokens after months of having the protocol functional because we focused on building utility first. Today, we want to acknowledge these early contributions by allowing all of these users to claim some tokens to join our governance.

We applied the following rules:

- **3 ɄDT per lock deployed**, on any of the production networks that we currently support (Ethereum, xDAI and Polygon).

- **1 ɄDT per key** purchased on any supported production network.

- **1 ɄDT for any ɄDT holder** with a balance of 3 ɄDT or more, as of September 1st 2021 at midnight (including liquidity providers on the Uniswap v2 pool)

We capped the amount of ɄDT that any address can claim to 10 ɄDT!

# Claiming... and delegating

**One of the most critical aspect of a successful DAO is participation**. For this reason, we have decided to alter [Uniswap's merkle-distributor contract](https://github.com/unlock-protocol/merkle-distributor), to require eligible addresses to delegate their tokens in order to claim them.

Our goal here is to make sure that all new tokens claimed are accounted for when it comes to governance. Additionally, since delegation applies to all of the tokens owned by an address, we expect that a large portion of the existing token holders will achieve delegation in order to claim additional tokens!

In order to ease the process, we identified a few members of our community who are willing to be delegates:

- Andreu: _Cybersecurity expert, Investor, lover of challenges and everything related to blockchain and technology._

- Aseem: _Currently building products at Uniswap Labs; Previously, cofounder at Open Collective and a PM at Dropbox, Google._

- Megan: _Decrypting crypto accounting._

- Elefterios: _Eleftherios is the founder of Radicle, a web-3 network for code collaboration._

Of course, you can very well pick any other address, but please, remember that it's very important for that delegate you chose to vote on proposals made by the community!

# Time limit

Finally, in order to make sure that tokens available for the airdrop are not wasted, we added a clean-up mechanism. This mechanism can be triggered by anyone after 1,000,000 blocks have been mined [from the moment](https://etherscan.io/block/13367076) the [airdrop contract](https://etherscan.io/address/0xFC6ed78d048Fdf1a22Bee990eA34995F9C029ad6) has been deployed. We expect this to be around 150 days, or around March 4th 2022!

At that point, all of the remaining tokens that have not been claimed will be transfered to the DAO, through the timelock contract, for the community to use as they want, along with the rest of the treasury.

What's next? [Delegate and claim your tokens now](https://airdrop.unlock-protocol.com/)!


Today, we're announcing a retro-active airdrop where anyone who contributed to Unlock's network can claim some ɄDT to join our governance

Everyone who used Unlock before September 1st can join our DAO!

Airdrop!

<p>Last week, we introduced the <a href="/blog/unlock-dao">Unlock DAO</a> where anyone can contribute proposals and vote on these in order to collectively govern the protocol and its treasury. Today, we're excited to announce that we're going one step further by doing a <strong>retro-active airdrop</strong>: anyone who has contributed to Unlock before September 1st 2021 is eligible to receive some ɄDT.</p>
<p>We expect to distribute <strong>up to 7,314 ɄDT</strong>! Claim your tokens now at <a href="https://airdrop.unlock-protocol.com/">https://airdrop.unlock-protocol.com/</a></p>
<p style="
    text-align: center;
"><img src="/images/blog/airdrop/coin.png" alt="Unlock DAO"></p>
<h1>Rewarding past contributions</h1>
<p>The protocol already <a href="https://docs.unlock-protocol.com/governance/the-unlock-token">mints and distributes</a> new tokens for every eligible key purchase. This very important mechanims lets us make sure that developers, creators and members who participate in the network's growth get a say in its governance.</p>
<p>However, we introduced the tokens after months of having the protocol functional because we focused on building utility first. Today, we want to acknowledge these early contributions by allowing all of these users to claim some tokens to join our governance.</p>
<p>We applied the following rules:</p>
<ul>
<li>
<p><strong>3 ɄDT per lock deployed</strong>, on any of the production networks that we currently support (Ethereum, xDAI and Polygon).</p>
</li>
<li>
<p><strong>1 ɄDT per key</strong> purchased on any supported production network.</p>
</li>
<li>
<p><strong>1 ɄDT for any ɄDT holder</strong> with a balance of 3 ɄDT or more, as of September 1st 2021 at midnight (including liquidity providers on the Uniswap v2 pool)</p>
</li>
</ul>
<p>We capped the amount of ɄDT that any address can claim to 10 ɄDT!</p>
<h1>Claiming... and delegating</h1>
<p><strong>One of the most critical aspect of a successful DAO is participation</strong>. For this reason, we have decided to alter <a href="https://github.com/unlock-protocol/merkle-distributor">Uniswap's merkle-distributor contract</a>, to require eligible addresses to delegate their tokens in order to claim them.</p>
<p>Our goal here is to make sure that all new tokens claimed are accounted for when it comes to governance. Additionally, since delegation applies to all of the tokens owned by an address, we expect that a large portion of the existing token holders will achieve delegation in order to claim additional tokens!</p>
<p>In order to ease the process, we identified a few members of our community who are willing to be delegates:</p>
<ul>
<li>
<p>Andreu: <em>Cybersecurity expert, Investor, lover of challenges and everything related to blockchain and technology.</em></p>
</li>
<li>
<p>Aseem: <em>Currently building products at Uniswap Labs; Previously, cofounder at Open Collective and a PM at Dropbox, Google.</em></p>
</li>
<li>
<p>Megan: <em>Decrypting crypto accounting.</em></p>
</li>
<li>
<p>Elefterios: <em>Eleftherios is the founder of Radicle, a web-3 network for code collaboration.</em></p>
</li>
</ul>
<p>Of course, you can very well pick any other address, but please, remember that it's very important for that delegate you chose to vote on proposals made by the community!</p>
<h1>Time limit</h1>
<p>Finally, in order to make sure that tokens available for the airdrop are not wasted, we added a clean-up mechanism. This mechanism can be triggered by anyone after 1,000,000 blocks have been mined <a href="https://etherscan.io/block/13367076">from the moment</a> the <a href="https://etherscan.io/address/0xFC6ed78d048Fdf1a22Bee990eA34995F9C029ad6">airdrop contract</a> has been deployed. We expect this to be around 150 days, or around March 4th 2022!</p>
<p>At that point, all of the remaining tokens that have not been claimed will be transfered to the DAO, through the timelock contract, for the community to use as they want, along with the rest of the treasury.</p>
<p>What's next? <a href="https://airdrop.unlock-protocol.com/">Delegate and claim your tokens now</a>!</p>
