
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

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.
<a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/The%20Defiant%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.
<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>


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

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:
<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>
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.
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!


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

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.
<a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/MyCrypto%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.
<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>

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

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?
<h2>Proxies on Ethereum</h2>
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.
<h2>Potential storage conflicts</h2>
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.
<img src="https://programtheblockchain.com/storage/fixed.png" alt="">
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>.
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 <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.
<h2>Testing upgrades</h2>
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 <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.
<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>
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 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 <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 :
<ul>
<li>
when a lock is created:
<ul>
<li>deploy a proxy</li>
<li>point it to the latest implemtation</li>
</ul>
</li>
<li>
when a lock is upgraded:
<ul>
<li>check if the caller is authorized as a lock manager</li>
<li>point to the new implementation</li>
</ul>
</li>
</ul>
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.
<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>
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).
<h2>Coming release</h2>
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 :)


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

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


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

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!
<img src="/images/blog/cohort-4/cohort-4.png" alt="Cohort 4">
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!
<h2>David Layton - Unfurl</h2>
<a href="https://www.linkedin.com/in/david-matthew-layton">https://www.linkedin.com/in/david-matthew-layton</a>
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)!
<h2>MJ Zilla - Element Integration</h2>
<a href="https://twitter.com/_mecyver">https://twitter.com/_mecyver</a>
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.
<h2>Stephen Grinalds - Chisos Capital</h2>
<a href="https://twitter.com/ChisosCapital">https://twitter.com/ChisosCapital</a>
Chisos Capital is utilizing Unlock to support their membership club and community of investors and entrepreneurs throughout their ecosystem.
<h2>Carlos Diaz-Padron and Gail Wilson - Metaphor</h2>
<a href="https://twitter.com/the_carlosdp">https://twitter.com/the_carlosdp</a>
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.
<h2>Fanny Lakoubay - BAD 2.0 (Blockchain Art Directory)</h2>
<a href="https://twitter.com/badOG_xyz">https://twitter.com/badOG_xyz</a>
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!
<h3>Are you ready to join our Grantees?</h3>
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>.
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>.
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>.


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

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>.
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.
<img src="/images/blog/bsc.png" alt="Binance Smart Chain">
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.
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 not yield UDT, but we're keeping this as an option if we start to see significant usage on that network!


![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

<img src="/images/blog/tokenized-memberships.jpg" alt="How communities and clubs can use Unlock">
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.
<h2>How this works</h2>
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.
<h2>Example: Dinner DAO</h2>
<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.
As an example, here’s the tech stack used and how Unlock enabled the Dinner DAO.
<h3>Creating locks</h3>
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.
<h3>Website with purchase link</h3>
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.
<h3>Voting for members</h3>
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.
<h3>Special access for members</h3>
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.
<h2>Other opportunities</h2>
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:
<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

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.
<a href="https://19942922.fs1.hubspotusercontent-na1.net/hubfs/19942922/Chroma%20Signet%20-%20Unlock%20Case%20Study.pdf">See the full case study</a>.
<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>


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!

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.
<img src="/images/blog/austin-robey.png" alt="Amber Case">
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.
What that let me turn the mic over to Austin to talk about his new role, and his vision for helping Unlock:
<blockquote>
I’m excited to begin work as Unlock Protocol’s Head of Growth.
</blockquote>
<blockquote>
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.
</blockquote>
<blockquote>
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.
</blockquote>
<blockquote>
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.
</blockquote>
<blockquote>
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.
</blockquote>
<blockquote>
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>.
</blockquote>
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>.