
The most recent NFT craze is bringing a lot of new users down the crypto rabbit-hole. Many of them are using Metamask as they discover the wonders of self-sovereign identity. Many of them are also discovering web3 through the lens of a native application such as [Rainbow](https://apps.apple.com/us/app/rainbow-ethereum-wallet/id1457119021), [Trust](https://trustwallet.com/), [Argent](https://www.argent.xyz/), and more.

Sometimes, these applications include browser web views, but they may not always be the user's preferred browser. In the Ethereum world, [Pedro Gomes](https://github.com/pedrouid) came up with the right idea: [WalletConnect](https://walletconnect.org/)!

Now that we're all used to ordering food with QR codes, it has become very simple to use a QR code to connect a dapp inside any web browser (👋 Firefox, Chrome or, Safari) to your wallet on a different device!

Today, we're excited to announce that all the Unlock front-end applications, from [our dashboard](https://app.unlock-protocol.com/dashboard) which lets creators deploy their own NFT contracts, to our paywall applications that lets them easily add locks to their web pages, support WalletConnect!


We have added Wallet Connect to all Unlock dapps! You can now connect to your dashboard or unlock memberships in your favorite applications from any web browser!

Let a thousand wallets bloom!

Support for WalletConnect

<p>The most recent NFT craze is bringing a lot of new users down the crypto rabbit-hole. Many of them are using Metamask as they discover the wonders of self-sovereign identity. Many of them are also discovering web3 through the lens of a native application such as <a href="https://apps.apple.com/us/app/rainbow-ethereum-wallet/id1457119021">Rainbow</a>, <a href="https://trustwallet.com/">Trust</a>, <a href="https://www.argent.xyz/">Argent</a>, and more.</p>
<p>Sometimes, these applications include browser web views, but they may not always be the user's preferred browser. In the Ethereum world, <a href="https://github.com/pedrouid">Pedro Gomes</a> came up with the right idea: <a href="https://walletconnect.org/">WalletConnect</a>!</p>
<p>Now that we're all used to ordering food with QR codes, it has become very simple to use a QR code to connect a dapp inside any web browser (👋 Firefox, Chrome or, Safari) to your wallet on a different device!</p>
<p>Today, we're excited to announce that all the Unlock front-end applications, from <a href="https://app.unlock-protocol.com/dashboard">our dashboard</a> which lets creators deploy their own NFT contracts, to our paywall applications that lets them easily add locks to their web pages, support WalletConnect!</p>



It is no secret that DeFi has trusted the Ethereum main chain's blocks. Over the last few months, it became clear that purchasing memberships would often not be economically viable, with gas fees costing up to $10 per transaction.

This leads us down the path of exploring our options. We are still profoundly **convinced that the Ethereum ecosystem is the right place to build Unlock**. Its developer community, the multitude of tools, its track record, and, most notably, the culture that it embodies are all assets that no other "layer 1" has been able to match.

We then decided to explore "layer 2" and found many options that Unlock will leverage shortly.

The first one is [xDAI](https://www.xdaichain.com/). xDAI is a blockchain that leverages Proof-of-Stake (much more eco-friendly!), uses a stable coin as its "core" currency, and has low gas fees (it costs about [costs about $0.000203 to purchase a membership](https://blockscout.com/poa/xdai/tx/0xcc0d93a59b85009a461a064542b8cb2e55be1dba525855c3b87418d02942951c/token-transfers)!) Today, we're very excited to see you deploy locks using our front-end and add these locks to your blogs and websites! Just make sure to point your wallet like [MetaMask to the xDAI network](https://www.xdaichain.com/for-users/wallets/metamask/metamask-setup), and transfer some of your DAI from the main Ethereum network. Everything else works out-of-the-box!

![XDAI](/images/blog/xdai/xdai.png)

Over the next few weeks, we will also add xUDT, the xDAI equivalent of our [Unlock Tokens](https://unlock-protocol.com/blog/unlock-tokens-launched), and add support for credit cards and more! If you have deployed a lock on xDAI, please message us on Telegram for a surprise!

Finally, we will also start exploring deploying Unlock on other chains such as [Polygon](https://polygon.technology/) or [BSC](https://bnbsmartchain.com/) as prompted by some of our early adopters, and explore [Optimism](https://optimism.io/) and [Arbitrum](https://offchainlabs.com/), to make sure that Unlock can grow and scale with the tens of thousands new NFT fans :)


Over the last few weeks, we heard many Unlock users who are complaining about very high gas prices on the Ethereum mainnet. Many of them have asked for xDAI support!

Unlock is now available on xDAI!

XDAI

<p>It is no secret that DeFi has trusted the Ethereum main chain's blocks. Over the last few months, it became clear that purchasing memberships would often not be economically viable, with gas fees costing up to $10 per transaction.</p>
<p>This leads us down the path of exploring our options. We are still profoundly <strong>convinced that the Ethereum ecosystem is the right place to build Unlock</strong>. Its developer community, the multitude of tools, its track record, and, most notably, the culture that it embodies are all assets that no other "layer 1" has been able to match.</p>
<p>We then decided to explore "layer 2" and found many options that Unlock will leverage shortly.</p>
<p>The first one is <a href="https://www.xdaichain.com/">xDAI</a>. xDAI is a blockchain that leverages Proof-of-Stake (much more eco-friendly!), uses a stable coin as its "core" currency, and has low gas fees (it costs about <a href="https://blockscout.com/poa/xdai/tx/0xcc0d93a59b85009a461a064542b8cb2e55be1dba525855c3b87418d02942951c/token-transfers">costs about $0.000203 to purchase a membership</a>!) Today, we're very excited to see you deploy locks using our front-end and add these locks to your blogs and websites! Just make sure to point your wallet like <a href="https://www.xdaichain.com/for-users/wallets/metamask/metamask-setup">MetaMask to the xDAI network</a>, and transfer some of your DAI from the main Ethereum network. Everything else works out-of-the-box!</p>
<p><img src="/images/blog/xdai/xdai.png" alt="XDAI"></p>
<p>Over the next few weeks, we will also add xUDT, the xDAI equivalent of our <a href="https://unlock-protocol.com/blog/unlock-tokens-launched">Unlock Tokens</a>, and add support for credit cards and more! If you have deployed a lock on xDAI, please message us on Telegram for a surprise!</p>
<p>Finally, we will also start exploring deploying Unlock on other chains such as <a href="https://polygon.technology/">Polygon</a> or <a href="https://bnbsmartchain.com/">BSC</a> as prompted by some of our early adopters, and explore <a href="https://optimism.io/">Optimism</a> and <a href="https://offchainlabs.com/">Arbitrum</a>, to make sure that Unlock can grow and scale with the tens of thousands new NFT fans :)</p>



Unlock is a protocol. Like any other protocol, it should not belong to anyone but its community of users and adopters. Today, we're very excited to introduce Unlock Discount Tokens and start the journey toward a fully decentralized protocol, where users co-own the protocol, as well as earn rewards for their use!

Don't forget to check the [step-by-step upgrades and deployments as documented on our wiki](https://github.com/unlock-protocol/unlock/wiki/The-Path-to-UDT!)!

![Decentralizing Unlock](/images/blog/launching-unlock-discount-tokens/decentralized-unlock.jpg)

# How does UDT work?

The Unlock Discount Token (UDT) is an **optional** ERC20 token that exists to add incentives to actors who are willing to grow and use the Unlock Protocol and network as well as progressively give them control of future upgrades. The smart contract which mints UDT has been deployed to the Ethereum main network and can be found at [`0x90de74265...`](https://etherscan.io/token/0x90de74265a416e1393a450752175aed98fe11517).

Unlock Discount Tokens are minted and granted as rewards upon key purchases to an address designated in the key purchase call, as shown on [this transaction for example](https://etherscan.io/tx/0xb0e5f95ea980c1f096a841e5507f465827411cc29f80f8b95971a5241d9e81bb). Like all of our contracts, it is fully verified on Etherscan and you can access the full [source code on GitHub](https://github.com/unlock-protocol/unlock/)!

We pre-mined 1,000,000 tokens and we'll distribute some of them to early investors and adopters soon, but this pre-mine will also quickly become a minority stake as the supply of tokens will grow as the network grows, since new tokens can be minted for every new key purchase.

As of now, the Unlock and UDT contracts are upgradable using OpenZeppelin and "owned" by a Gnosis multisig wallets whose signers are Unlock employees. Our goal is to soon decentralize that mechanism so that upgrades can only be triggered by UDT holders, after a voting process through a DAO, where votes are weighted by UDT ownership!

**Additionally, the first upgrade that we will then submit will add a mechanism that lets UDT holders claim discounts on their key purchases!**

Our [wiki provides a long description](https://github.com/unlock-protocol/unlock/wiki/The-Unlock-Discount-Tokens) of how UDT works.

# How can I earn UDT?

From now on, there is only a single way to create (and earn) new tokens: making key purchases. The number of tokens minted is based on the value of the purchase relative to the size of the overall network. This means that when the network is small, the number of tokens minted will be relatively larger than when the network is getting large. **This rewards early adopters more**!

The number of tokens minted is also capped to the gas spent by the transaction, so that it is always cheaper to purchase UDT from an exchange [such as Uniswap](https://app.uniswap.org/#/add/ETH/0x90DE74265a416e1393A450752175AED98fe11517) than it would be to purchase keys for yourself and earn tokens doing it.

It's important to note that even though the supply of tokens will grow forever as the network grows, the growth of the supply will slow down forever as well, which means that it is much easier to accumulate tokens in the early days of the network than once it will be larger.

# What is next?

The next step toward a fully decentralized Unlock Protocol is to start working on moving away from our multisignature based upgrades to upgrades driven by a Decentralized Autonomous Organization. This will be our focus in the next few months.

We will also work on allowing token holders to claim discounts on their purchases as we think it is important to add financial rewards to stakeholders.

Do you want to learn more? Are you interested in joining us? [Reach out on Discord](https://discord.gg/Ah6ZEJyTDp)!


As an open protocol for memberships, we want Unlock to belong to its users. Today we are introducing the protocol's native token.

Starting the decentralization of Unlock!

Launching Unlock Discount Tokens

<p>Unlock is a protocol. Like any other protocol, it should not belong to anyone but its community of users and adopters. Today, we're very excited to introduce Unlock Discount Tokens and start the journey toward a fully decentralized protocol, where users co-own the protocol, as well as earn rewards for their use!</p>
<p>Don't forget to check the <a href="https://github.com/unlock-protocol/unlock/wiki/The-Path-to-UDT!">step-by-step upgrades and deployments as documented on our wiki</a>!</p>
<p><img src="/images/blog/launching-unlock-discount-tokens/decentralized-unlock.jpg" alt="Decentralizing Unlock"></p>
<h1>How does UDT work?</h1>
<p>The Unlock Discount Token (UDT) is an <strong>optional</strong> ERC20 token that exists to add incentives to actors who are willing to grow and use the Unlock Protocol and network as well as progressively give them control of future upgrades. The smart contract which mints UDT has been deployed to the Ethereum main network and can be found at <a href="https://etherscan.io/token/0x90de74265a416e1393a450752175aed98fe11517"><code>0x90de74265...</code></a>.</p>
<p>Unlock Discount Tokens are minted and granted as rewards upon key purchases to an address designated in the key purchase call, as shown on <a href="https://etherscan.io/tx/0xb0e5f95ea980c1f096a841e5507f465827411cc29f80f8b95971a5241d9e81bb">this transaction for example</a>. Like all of our contracts, it is fully verified on Etherscan and you can access the full <a href="https://github.com/unlock-protocol/unlock/">source code on GitHub</a>!</p>
<p>We pre-mined 1,000,000 tokens and we'll distribute some of them to early investors and adopters soon, but this pre-mine will also quickly become a minority stake as the supply of tokens will grow as the network grows, since new tokens can be minted for every new key purchase.</p>
<p>As of now, the Unlock and UDT contracts are upgradable using OpenZeppelin and "owned" by a Gnosis multisig wallets whose signers are Unlock employees. Our goal is to soon decentralize that mechanism so that upgrades can only be triggered by UDT holders, after a voting process through a DAO, where votes are weighted by UDT ownership!</p>
<p><strong>Additionally, the first upgrade that we will then submit will add a mechanism that lets UDT holders claim discounts on their key purchases!</strong></p>
<p>Our <a href="https://github.com/unlock-protocol/unlock/wiki/The-Unlock-Discount-Tokens">wiki provides a long description</a> of how UDT works.</p>
<h1>How can I earn UDT?</h1>
<p>From now on, there is only a single way to create (and earn) new tokens: making key purchases. The number of tokens minted is based on the value of the purchase relative to the size of the overall network. This means that when the network is small, the number of tokens minted will be relatively larger than when the network is getting large. <strong>This rewards early adopters more</strong>!</p>
<p>The number of tokens minted is also capped to the gas spent by the transaction, so that it is always cheaper to purchase UDT from an exchange <a href="https://app.uniswap.org/#/add/ETH/0x90DE74265a416e1393A450752175AED98fe11517">such as Uniswap</a> than it would be to purchase keys for yourself and earn tokens doing it.</p>
<p>It's important to note that even though the supply of tokens will grow forever as the network grows, the growth of the supply will slow down forever as well, which means that it is much easier to accumulate tokens in the early days of the network than once it will be larger.</p>
<h1>What is next?</h1>
<p>The next step toward a fully decentralized Unlock Protocol is to start working on moving away from our multisignature based upgrades to upgrades driven by a Decentralized Autonomous Organization. This will be our focus in the next few months.</p>
<p>We will also work on allowing token holders to claim discounts on their purchases as we think it is important to add financial rewards to stakeholders.</p>
<p>Do you want to learn more? Are you interested in joining us? <a href="https://discord.gg/Ah6ZEJyTDp">Reach out on Discord</a>!</p>



The most exciting aspects of Ethereum is its composability. For example, locks can use stable coins such as DAI or USDc for their pricing. These coins are both using the ERC20 token standard. Today we're showing how we leverage another characteristic of the ERC20 specification to make recurring memberships.

# Introducing the Key Purchaser contract

Locks have a pretty simple mechanism to "purchase" memberships, which has one handy characteristic: **the sender of the transaction can specify the recipient of the membership**. It means that someone can buy a key
(membership) for themselves or, for someone else. We already use this mechanism for [our credit card support](/blog/unlock-with-credit-cards), for example.

We created a new contract, called the **Key Purchaser**, whose sole purpose is to purchase keys to a specific lock. This contract enables recurring memberships!

# How does it work?

1. The lock owner **deploys a Key Purchaser** contract dedicated to their lock. When they do so, they define some characteristics for the recurring memberships:

   - the frequency at which keys can be renewed,
   - the earliest an existing key can be renewed (before it expires),
   - the maximum price to pay per key (in case the lock's key price was increased)
   - a reward for the transaction sender (see below!)

2. Rather than buying keys immediately, prospective members use the ERC20 allowance mechanism to **allow the Key Purchaser** contract to spend some of their ERC20 tokens. The amount that they approve should cover multiple renewals, based on the use case.

3. A third party application should monitor these approvals, and, for each of them, if the approver does not have a valid key to the lock, it should call the Key Purchaser contract to **perform a purchase**. That transaction will only succeed if all of the following pre-requisites are met:

   - The approver has approved an amount that is large enough
   - The approver has enough ERC20 to perform the purchase
   - The key price has changed significantly
   - The approver does not have a key or has a key which is soon to be expired

4. If the transaction succeeds, the member will see their ERC20 being spent. Some of the tokens are used to purchase the key and the balancer to provide a reward to the 3rd party application, which sends the transaction. The reward's goal is to cover for the gas spent to perform the transaction.

# A full example

A lock priced in DAI was deployed at this address: [`0x72ef8d4a4...`](https://etherscan.io/address/0x72ef8d4a46c94fe739f880b690bff2a825113abf). The lock's name is _v7 DAI Lock_. The key price is 1 DAI, and the duration is 1 day.

A Key Purchaser was deployed at this address: [`0xa1c718312fd0...`](https://etherscan.io/address/0xa1c718312fd0252540e5ecf6b4cd83fdbfa06acb). This Key Purchaser allows for a maximum price of 1 DAI (in other words, all renewals would fail if the price was increased). The Key Purchaser enables for renewals every 20 hours (72000 seconds) and would only succeed if it was mined at most 1 hour (3600 seconds) before the expiration of a previous key. Finally, there is a reward of 0.1 DAI for the address which sent the transaction.

A user [approved the key purchaser](https://etherscan.io/tx/0x5d3fb6902a3272651460d1ada2abe3b2ab8433f24c9378853b6a4095afc127ce) to spend up to 10 DAI to cover multiple renewals.

Another user then [sent a transaction to the key purchaser](https://etherscan.io/tx/0xfd5f8dd28cd9f20da00435a562eda0171ecdfa21c8cb0f2367d888f407465aed) to perform the actual purchase. The Etherscan UI provides a good understanding of what happened.

![key purchase](/images/blog/recurring-memberships/transaction.png)

We can see 1.1 DAI transferred from the member's address, 1 DAI sent to the lock, 0.1 DAI sent to the sender.
Additionally, a new NFT for the lock was minted and granted to the members!

Easter egg: The membership has now expired, which means it can be renewed... and there is a 0.1 DAI reward to whoever sends it!

## Next steps

We are [working](https://github.com/unlock-protocol/unlock/issues/6736) on running a 3rd party service that would issue transactions to execute key purchases. This service will monitor deployments of new key purchasers and the corresponding ERC20 approvals. For each of these, it will check whether the user should get a new key and issue a transaction on that case. This service will only execute transactions where the reward covers the gas we would spend.

Another next step is to update our paywall application to support recurring memberships.


Leveraring the ERC20 approach to allowances lets creators easily create a recurring membership!

The Unlock Protocol supports recurring memberships!

Recurring Memberships

<p>The most exciting aspects of Ethereum is its composability. For example, locks can use stable coins such as DAI or USDc for their pricing. These coins are both using the ERC20 token standard. Today we're showing how we leverage another characteristic of the ERC20 specification to make recurring memberships.</p>
<h1>Introducing the Key Purchaser contract</h1>
<p>Locks have a pretty simple mechanism to "purchase" memberships, which has one handy characteristic: <strong>the sender of the transaction can specify the recipient of the membership</strong>. It means that someone can buy a key
(membership) for themselves or, for someone else. We already use this mechanism for <a href="/blog/unlock-with-credit-cards">our credit card support</a>, for example.</p>
<p>We created a new contract, called the <strong>Key Purchaser</strong>, whose sole purpose is to purchase keys to a specific lock. This contract enables recurring memberships!</p>
<h1>How does it work?</h1>
<ol>
<li>
<p>The lock owner <strong>deploys a Key Purchaser</strong> contract dedicated to their lock. When they do so, they define some characteristics for the recurring memberships:</p>
<ul>
<li>the frequency at which keys can be renewed,</li>
<li>the earliest an existing key can be renewed (before it expires),</li>
<li>the maximum price to pay per key (in case the lock's key price was increased)</li>
<li>a reward for the transaction sender (see below!)</li>
</ul>
</li>
<li>
<p>Rather than buying keys immediately, prospective members use the ERC20 allowance mechanism to <strong>allow the Key Purchaser</strong> contract to spend some of their ERC20 tokens. The amount that they approve should cover multiple renewals, based on the use case.</p>
</li>
<li>
<p>A third party application should monitor these approvals, and, for each of them, if the approver does not have a valid key to the lock, it should call the Key Purchaser contract to <strong>perform a purchase</strong>. That transaction will only succeed if all of the following pre-requisites are met:</p>
<ul>
<li>The approver has approved an amount that is large enough</li>
<li>The approver has enough ERC20 to perform the purchase</li>
<li>The key price has changed significantly</li>
<li>The approver does not have a key or has a key which is soon to be expired</li>
</ul>
</li>
<li>
<p>If the transaction succeeds, the member will see their ERC20 being spent. Some of the tokens are used to purchase the key and the balancer to provide a reward to the 3rd party application, which sends the transaction. The reward's goal is to cover for the gas spent to perform the transaction.</p>
</li>
</ol>
<h1>A full example</h1>
<p>A lock priced in DAI was deployed at this address: <a href="https://etherscan.io/address/0x72ef8d4a46c94fe739f880b690bff2a825113abf"><code>0x72ef8d4a4...</code></a>. The lock's name is <em>v7 DAI Lock</em>. The key price is 1 DAI, and the duration is 1 day.</p>
<p>A Key Purchaser was deployed at this address: <a href="https://etherscan.io/address/0xa1c718312fd0252540e5ecf6b4cd83fdbfa06acb"><code>0xa1c718312fd0...</code></a>. This Key Purchaser allows for a maximum price of 1 DAI (in other words, all renewals would fail if the price was increased). The Key Purchaser enables for renewals every 20 hours (72000 seconds) and would only succeed if it was mined at most 1 hour (3600 seconds) before the expiration of a previous key. Finally, there is a reward of 0.1 DAI for the address which sent the transaction.</p>
<p>A user <a href="https://etherscan.io/tx/0x5d3fb6902a3272651460d1ada2abe3b2ab8433f24c9378853b6a4095afc127ce">approved the key purchaser</a> to spend up to 10 DAI to cover multiple renewals.</p>
<p>Another user then <a href="https://etherscan.io/tx/0xfd5f8dd28cd9f20da00435a562eda0171ecdfa21c8cb0f2367d888f407465aed">sent a transaction to the key purchaser</a> to perform the actual purchase. The Etherscan UI provides a good understanding of what happened.</p>
<p><img src="/images/blog/recurring-memberships/transaction.png" alt="key purchase"></p>
<p>We can see 1.1 DAI transferred from the member's address, 1 DAI sent to the lock, 0.1 DAI sent to the sender.
Additionally, a new NFT for the lock was minted and granted to the members!</p>
<p>Easter egg: The membership has now expired, which means it can be renewed... and there is a 0.1 DAI reward to whoever sends it!</p>
<h2>Next steps</h2>
<p>We are <a href="https://github.com/unlock-protocol/unlock/issues/6736">working</a> on running a 3rd party service that would issue transactions to execute key purchases. This service will monitor deployments of new key purchasers and the corresponding ERC20 approvals. For each of these, it will check whether the user should get a new key and issue a transaction on that case. This service will only execute transactions where the reward covers the gas we would spend.</p>
<p>Another next step is to update our paywall application to support recurring memberships.</p>



Locks are primitives which manage access control. When a creator deploys a lock, they can integrate it with other primitives on the Ethereum chain, [such as any ERC20](https://unlock-protocol.com/blog/erc20-locks) (including stable coins or personal tokens).

When deploying them, a creator can customize their parameters (price and duration of the keys, maximum number of keys... etc). At a lower level, they are also _programmable_ through the use callbacks.

Any lock manager (learn more about roles for locks) can point to a 3rd party contract which would implement the `ILockKeyPurchaseHook` [interface](https://github.com/unlock-protocol/unlock/blob/master/smart-contracts/contracts/interfaces/hooks/ILockKeyPurchaseHook.sol) and/or the `ILockKeyCancelHook` [interface](https://github.com/unlock-protocol/unlock/blob/master/smart-contracts/contracts/interfaces/hooks/ILockKeyCancelHook.sol). The first one is invoked when a key purchase is performed, while the second would be called when a key has been cancelled.

![Setting hooks](/images/blog/hooks/settings-hooks.png)

# Key Purchase Hook

The Key purchase hook actually has 2 entry points:

- `keyPurchasePrice` which is invoked _before_ the key purchase itself
- `onKeyPurchase` which is invoked _after_ the key purchase.

The first hook `keyPurchasePrice` can be used to alter the price which is actually paid by the member to purchase a membership, or even prevent it completely. For example, you would use this hook to apply a discount code, or even prevent someone from buying a membership unless they are, say an accredited investor.

One of the thing that excites us the most about this is the ability to "chain" memberships. For example, someone would pay less for a membership if they already have a membership to another lock.

The second hook, `onKeyPurchase`, should be used to update the state of the system, as it will not alter the actual key purchase transaction. This is useful for example, if you want to create a bonding curve for the key price of a lock. The hook can then be invoked to change the lock's key price for every purchase... etc.

# Key Cancel Hook

This hook only has a single entry point, `onKeyCancel`, which is invoked when a member cancels (burns) their key. Even though it could revert to prevent refunds, we recommend that it is only used to alter state as the cancellation parameters (including the amount to be refunded can be altered using other mechanisms)

# Examples

Our docs provide 2 examples for how to use callback hooks. The first one shows how to create a discount code for key purchases on a hook. This hook is quite interesting because it solves the challenge of keeping the discount code secret (it is not submitted when performing the purchase!). The second example shows an example where key purchases are restricted to people who have a special access code.

With Ethereum, smart contracts are all running in the same "computer" which opens the door for very deep integrations between different components which provide different features.


Our Public Lock contracts implements a hook pattern to let lock owners customize the behavior of their lock upon key purchases and key cancellations.

The "callback" pattern is a very good way to customize a lock's behavior!

Hooks

<p>Locks are primitives which manage access control. When a creator deploys a lock, they can integrate it with other primitives on the Ethereum chain, <a href="https://unlock-protocol.com/blog/erc20-locks">such as any ERC20</a> (including stable coins or personal tokens).</p>
<p>When deploying them, a creator can customize their parameters (price and duration of the keys, maximum number of keys... etc). At a lower level, they are also <em>programmable</em> through the use callbacks.</p>
<p>Any lock manager (learn more about roles for locks) can point to a 3rd party contract which would implement the <code>ILockKeyPurchaseHook</code> <a href="https://github.com/unlock-protocol/unlock/blob/master/smart-contracts/contracts/interfaces/hooks/ILockKeyPurchaseHook.sol">interface</a> and/or the <code>ILockKeyCancelHook</code> <a href="https://github.com/unlock-protocol/unlock/blob/master/smart-contracts/contracts/interfaces/hooks/ILockKeyCancelHook.sol">interface</a>. The first one is invoked when a key purchase is performed, while the second would be called when a key has been cancelled.</p>
<p><img src="/images/blog/hooks/settings-hooks.png" alt="Setting hooks"></p>
<h1>Key Purchase Hook</h1>
<p>The Key purchase hook actually has 2 entry points:</p>
<ul>
<li><code>keyPurchasePrice</code> which is invoked <em>before</em> the key purchase itself</li>
<li><code>onKeyPurchase</code> which is invoked <em>after</em> the key purchase.</li>
</ul>
<p>The first hook <code>keyPurchasePrice</code> can be used to alter the price which is actually paid by the member to purchase a membership, or even prevent it completely. For example, you would use this hook to apply a discount code, or even prevent someone from buying a membership unless they are, say an accredited investor.</p>
<p>One of the thing that excites us the most about this is the ability to "chain" memberships. For example, someone would pay less for a membership if they already have a membership to another lock.</p>
<p>The second hook, <code>onKeyPurchase</code>, should be used to update the state of the system, as it will not alter the actual key purchase transaction. This is useful for example, if you want to create a bonding curve for the key price of a lock. The hook can then be invoked to change the lock's key price for every purchase... etc.</p>
<h1>Key Cancel Hook</h1>
<p>This hook only has a single entry point, <code>onKeyCancel</code>, which is invoked when a member cancels (burns) their key. Even though it could revert to prevent refunds, we recommend that it is only used to alter state as the cancellation parameters (including the amount to be refunded can be altered using other mechanisms)</p>
<h1>Examples</h1>
<p>Our docs provide 2 examples for how to use callback hooks. The first one shows how to create a discount code for key purchases on a hook. This hook is quite interesting because it solves the challenge of keeping the discount code secret (it is not submitted when performing the purchase!). The second example shows an example where key purchases are restricted to people who have a special access code.</p>
<p>With Ethereum, smart contracts are all running in the same "computer" which opens the door for very deep integrations between different components which provide different features.</p>



# ABI

We write our smart contracts using the [Solidity](https://solidity.readthedocs.io/) language. Once compiled they are deployed to the Ethereum chain. Ethereum nodes, such as the ones from [Alchemy](https://alchemyapi.io/) (which we use and love!), provide RPC endpoints to retrieve or alter the state of the contracts.

The "description" of the method calls is inside of the Application Binary Interface (ABI). The Contract ABI is the standard way to interact with contracts in the Ethereum ecosystem, both from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type, as described in this specification. The encoding is not self describing and thus requires a schema in order to decode.

We verify all of our contract on Etherscan, which means that creators and consumers can easily inspect each implementation and ensure that the protocol works as they expect. You can also use Etherscan to inspect the ABI themselves. See for example [the ABI of the lock on this blog](https://etherscan.io/address/0xCE62D71c768aeD7EA034c72a1bc4CF58830D9894#code).

# npm modules

3rd party developers can use our ABIs directly, but, for convenience, we also provide npm modules. These modules can be used inside of JavaScript applications, either front-end or backend! The module can also be used with other Solidity applications since several solidity developer tools, such as Truffle! For example, you can look at [our very own smart contract extensions](https://github.com/unlock-protocol/unlock/tree/master/smart-contract-extensions)!

We publish [each and every Unlock ABI](https://docs.unlock-protocol.com/core-protocol/) as module for every version that we publish: `@unlock-protocol/contracts`

The Unlock contract, which is a factory contract will always deploy locks from the _latest_ version, but older locks are, by design, not updagradable by us, which means that they will remain on the version at the time of their deployment. You should use etherscan to inspect which version a specific lock uses!


We publish our ABI as npm modules

Unlock ABI modules

<h1>ABI</h1>
<p>We write our smart contracts using the <a href="https://solidity.readthedocs.io/">Solidity</a> language. Once compiled they are deployed to the Ethereum chain. Ethereum nodes, such as the ones from <a href="https://alchemyapi.io/">Alchemy</a> (which we use and love!), provide RPC endpoints to retrieve or alter the state of the contracts.</p>
<p>The "description" of the method calls is inside of the Application Binary Interface (ABI). The Contract ABI is the standard way to interact with contracts in the Ethereum ecosystem, both from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type, as described in this specification. The encoding is not self describing and thus requires a schema in order to decode.</p>
<p>We verify all of our contract on Etherscan, which means that creators and consumers can easily inspect each implementation and ensure that the protocol works as they expect. You can also use Etherscan to inspect the ABI themselves. See for example <a href="https://etherscan.io/address/0xCE62D71c768aeD7EA034c72a1bc4CF58830D9894#code">the ABI of the lock on this blog</a>.</p>
<h1>npm modules</h1>
<p>3rd party developers can use our ABIs directly, but, for convenience, we also provide npm modules. These modules can be used inside of JavaScript applications, either front-end or backend! The module can also be used with other Solidity applications since several solidity developer tools, such as Truffle! For example, you can look at <a href="https://github.com/unlock-protocol/unlock/tree/master/smart-contract-extensions">our very own smart contract extensions</a>!</p>
<p>We publish <a href="https://docs.unlock-protocol.com/core-protocol/">each and every Unlock ABI</a> as module for every version that we publish: <code>@unlock-protocol/contracts</code></p>
<p>The Unlock contract, which is a factory contract will always deploy locks from the <em>latest</em> version, but older locks are, by design, not updagradable by us, which means that they will remain on the version at the time of their deployment. You should use etherscan to inspect which version a specific lock uses!</p>



The latest release of the Unlock Paywall includes a feature that allows the host page to share the provider it uses with the embedded iframe. Let's take a look at why that's important, and what this enables.

# Not All Dapp Browsers Behave The Same

This isn't the first code we've written to share the provider in use on the host page with the paywall. The very first iteration of this feature was a dirrect response to browser compatibility issues. Our paywall is itself a dapp that gets embedded in an iframe on a host page (which may or may not be a dapp). Some browsers, like Metamask on desktop, will inject a provider into the global environment of an iframe just like they do on any other page. However, some other browsers, like Trust Wallet on mobile devices, do not. For those users, our paywall would appear to be broken because it does not have full functionality without a provider.

Our earliest solution to this challenge was perhaps a bit more complicated than necessary, but it did resolve the problem. The latest iteration keeps this important functionality, but does so in a simpler, easier to maintain way.

# It's Not Enough to Have _Just Any_ Provider

As the Web3 ecosystem has matured, new options for providers have become available, and our app wasn't quite ready for them. We don't necessarily want to always use the provider at `window.ethereum`, because if the host site wants to implement Web3Modal or WalletConnect (which usually return a provider object but do not inject them into the global environment), the paywall won't have access to them without some extra manual work from the implementer.

To that end, the latest version of Unlock's delegated provider has fewer baked-in assumptions about how your app or site is constructed. It's more flexible, which makes it work in a broader set of environments. Stay tuned for a blog post coming soon to see how you can use some advanced paywall integration techniques to enable one of these provider solutions!


The delegated provider allows the embedded paywall to synchronize with the provider used on the host page

Enabling richer provider interactions

Unlock's Delegated Provider

<p>The latest release of the Unlock Paywall includes a feature that allows the host page to share the provider it uses with the embedded iframe. Let's take a look at why that's important, and what this enables.</p>
<h1>Not All Dapp Browsers Behave The Same</h1>
<p>This isn't the first code we've written to share the provider in use on the host page with the paywall. The very first iteration of this feature was a dirrect response to browser compatibility issues. Our paywall is itself a dapp that gets embedded in an iframe on a host page (which may or may not be a dapp). Some browsers, like Metamask on desktop, will inject a provider into the global environment of an iframe just like they do on any other page. However, some other browsers, like Trust Wallet on mobile devices, do not. For those users, our paywall would appear to be broken because it does not have full functionality without a provider.</p>
<p>Our earliest solution to this challenge was perhaps a bit more complicated than necessary, but it did resolve the problem. The latest iteration keeps this important functionality, but does so in a simpler, easier to maintain way.</p>
<h1>It's Not Enough to Have <em>Just Any</em> Provider</h1>
<p>As the Web3 ecosystem has matured, new options for providers have become available, and our app wasn't quite ready for them. We don't necessarily want to always use the provider at <code>window.ethereum</code>, because if the host site wants to implement Web3Modal or WalletConnect (which usually return a provider object but do not inject them into the global environment), the paywall won't have access to them without some extra manual work from the implementer.</p>
<p>To that end, the latest version of Unlock's delegated provider has fewer baked-in assumptions about how your app or site is constructed. It's more flexible, which makes it work in a broader set of environments. Stay tuned for a blog post coming soon to see how you can use some advanced paywall integration techniques to enable one of these provider solutions!</p>



The blockchain movement started with crypto-currencies. Bitcoin became the first permission-less and decentralized money. Money balances are "state" stored in a ledger. Ethereum went further by becoming the first blockchain which can store any kind of "state". At Unlock, we think it's a great [platform to store memberships](https://unlock-protocol.com/blog/protocol-for-membership/).

About 6 months ago, we introduced our [Unlock accounts](https://unlock-protocol.com/blog/unlock-user-accounts/), which are easy ways for people who do no have a crypto wallet, or not do own crypto-currencies to easily and **instantly** purchase their memberships. We hide the "crypto" complexity under the hood (seed phrases, gas fees... etc) so that internet users can easily Unlock content, without having to learn new paradigms... until [they actually want to](https://unlock-protocol.com/blog/ejecting-account/)!

Today, I am very proud to introduce the next iteration of our work on supporting credit cards. Starting now, **crypto users can also purchase memberships using their credit cards** on selected locks.

We believe that wallets are great to store money and access keys, but that they are also a very good identity mechanism. In other words, you should be able to [login into any website using your wallet](https://www.nickgrossman.is/2020/digital-bearer-assets/), rather than using an email address and password. Whether the wallet actually holds money could almost be irrelevant. As such, we think memberships should be attached to the wallet, whether they have actually been purchased _from_ the wallet, or using another payment mechanism, such as credit cards!

1. When a user finds a lock with credit cards enabled, they can select _Credit Card_ as their payment mechanism.
2. The price will be slightly higher to cover credit card fees.
3. The user is then asked to enter their credit card number and sign it with their crypto wallet
4. Once submitted, our backend will then charge the card, and issue the corresponding NFT!

This is by far the easiest way to purchase your first crypto asset. Want to try by yourself? Check these locked sites:

- [Livepeer dashboards on Scout](https://medium.com/@scout_cool/announcing-livepeer-orchestrator-dashboard-with-an-unlock-fca60750843b), like [this one](https://scout.cool/livepeer/mainnet/dashboards/5e28c582bfbf6c00177109e0?&nodeaddress=0xE9E284277648fcdb09B8EfC1832c73c09b5Ecf59)
- Ben's free [startup feedback sessions](https://werd.io/2020/free-startup-feedback-sessions-for-members) (only for members!)
- Stake for the [HackMoney hackathon](https://hack.ethglobal.co/online/hacker)

Soon, we will introduce another iteration of our work on the credit card front. Our goal is to enable credit card purchase for any user (who have their own wallets or not), on any lock, whether they use stable coins or not. We believe this will unlock the next 10M crypto users ;)


Unlock memberships with credit cards, whether you use a crypto wallet, or not!

Unlock memberships with credit cards, whether you use a crypto wallet, or not.

Unlocking with a credit card

<p>The blockchain movement started with crypto-currencies. Bitcoin became the first permission-less and decentralized money. Money balances are "state" stored in a ledger. Ethereum went further by becoming the first blockchain which can store any kind of "state". At Unlock, we think it's a great <a href="https://unlock-protocol.com/blog/protocol-for-membership/">platform to store memberships</a>.</p>
<p>About 6 months ago, we introduced our <a href="https://unlock-protocol.com/blog/unlock-user-accounts/">Unlock accounts</a>, which are easy ways for people who do no have a crypto wallet, or not do own crypto-currencies to easily and <strong>instantly</strong> purchase their memberships. We hide the "crypto" complexity under the hood (seed phrases, gas fees... etc) so that internet users can easily Unlock content, without having to learn new paradigms... until <a href="https://unlock-protocol.com/blog/ejecting-account/">they actually want to</a>!</p>
<p>Today, I am very proud to introduce the next iteration of our work on supporting credit cards. Starting now, <strong>crypto users can also purchase memberships using their credit cards</strong> on selected locks.</p>
<p>We believe that wallets are great to store money and access keys, but that they are also a very good identity mechanism. In other words, you should be able to <a href="https://www.nickgrossman.is/2020/digital-bearer-assets/">login into any website using your wallet</a>, rather than using an email address and password. Whether the wallet actually holds money could almost be irrelevant. As such, we think memberships should be attached to the wallet, whether they have actually been purchased <em>from</em> the wallet, or using another payment mechanism, such as credit cards!</p>
<ol>
<li>When a user finds a lock with credit cards enabled, they can select <em>Credit Card</em> as their payment mechanism.</li>
<li>The price will be slightly higher to cover credit card fees.</li>
<li>The user is then asked to enter their credit card number and sign it with their crypto wallet</li>
<li>Once submitted, our backend will then charge the card, and issue the corresponding NFT!</li>
</ol>
<p>This is by far the easiest way to purchase your first crypto asset. Want to try by yourself? Check these locked sites:</p>
<ul>
<li><a href="https://medium.com/@scout_cool/announcing-livepeer-orchestrator-dashboard-with-an-unlock-fca60750843b">Livepeer dashboards on Scout</a>, like <a href="https://scout.cool/livepeer/mainnet/dashboards/5e28c582bfbf6c00177109e0?&#x26;nodeaddress=0xE9E284277648fcdb09B8EfC1832c73c09b5Ecf59">this one</a></li>
<li>Ben's free <a href="https://werd.io/2020/free-startup-feedback-sessions-for-members">startup feedback sessions</a> (only for members!)</li>
<li>Stake for the <a href="https://hack.ethglobal.co/online/hacker">HackMoney hackathon</a></li>
</ul>
<p>Soon, we will introduce another iteration of our work on the credit card front. Our goal is to enable credit card purchase for any user (who have their own wallets or not), on any lock, whether they use stable coins or not. We believe this will unlock the next 10M crypto users ;)</p>



The Unlock Paywall has evolved substantially over the past year, from a more traditional paywall that blocked a page to a configurable and embeddable tool that enabled all kinds of memberships. Here's our latest release, crafted in direct response to our customers' needs and our own experience.

# Subtracting Weight Makes You Faster Everywhere

Modern web apps are usually quite large, which makes them less usable on mobile networks or low-bandwidth connections. The Unlock Paywall feels this issue more acutely than most applications because it's intended to be embedded on another page, which itself is probably quite large. As adoption of our protocol grew, we identified several key challenges we'd have to solve:

- Too large a bundle size
- Too many network requests
- Too many dependencies

## Bundle Size

The previous iteration of our paywall consisted of several subsytems. We did load these separately to avoid having one huge blob that needed to come down before anything could start, but it was clear to us that we could go further. We were able to shrink our architecture to only require a very slim wrapper script loaded into the client page and one iframe to handle key purchases. Because the key purchase iframe is lazy-loaded, most interactions with a locked page don't need to download it at all.

## Too Many Network Requests

Previously, our application did a lot of polling to various places to maintain an accurate picture of a member's status. Over time we've managed to shrink this dramatically by choosing more carefully what information we really need for a good checkout experience, and being more clever about how to get that subset of data. This has been an ongoing process for some time now, but it culminates in the latest paywall release which prunes some of the chattiest parts of the application.

## Too Many Dependencies

We previously used a library to handle Web3 calls on the paywall (to some extent we still do, but only in the lazy-loaded checkout iframe). We found that this library contributed some substantial weight to our application, when it was only being used for a handful of calls. We found that it wasn't hard for us to manually implement methods to make these calls to the chain, which saved us both time and space.

# Greater Capabilities With Less Code

We've managed to make these changes without compromising the functionality of our paywall application at all. In fact, this rearchitecture made it possible to move more quickly while implementing new features that previously would have taken a lot more effort. The first and most visible update is a UI overhaul that takes up less space and works a lot better on mobile devices. We'll have more news on what's next in the pipeline in future blog posts.

# An Evergreen Deployment Model

If you've integrated Unlock on your site before, you'll have noticed that you load the script `unlock.1.0.min.js`. So is today's announcement about `unlock.2.0.min.js`? Nope! Because we aren't making any breaking changes to the Paywall API and we want to ensure that consumers can smoothly and quickly get the latest and greatest code, we've moved to an explicitly "evergreen" model. Loading `unlock.latest.min.js` on your page will ensure that you're always up-to-date and get continuous improvements with every production deploy we do. [Our docs](https://docs.unlock-protocol.com) have been updated to this effect.


Unlock introduces a new paywall architecture in response to customer needs

Leaner, faster, and evergreen

Introducing the Latest Unlock Paywall

<p>The Unlock Paywall has evolved substantially over the past year, from a more traditional paywall that blocked a page to a configurable and embeddable tool that enabled all kinds of memberships. Here's our latest release, crafted in direct response to our customers' needs and our own experience.</p>
<h1>Subtracting Weight Makes You Faster Everywhere</h1>
<p>Modern web apps are usually quite large, which makes them less usable on mobile networks or low-bandwidth connections. The Unlock Paywall feels this issue more acutely than most applications because it's intended to be embedded on another page, which itself is probably quite large. As adoption of our protocol grew, we identified several key challenges we'd have to solve:</p>
<ul>
<li>Too large a bundle size</li>
<li>Too many network requests</li>
<li>Too many dependencies</li>
</ul>
<h2>Bundle Size</h2>
<p>The previous iteration of our paywall consisted of several subsytems. We did load these separately to avoid having one huge blob that needed to come down before anything could start, but it was clear to us that we could go further. We were able to shrink our architecture to only require a very slim wrapper script loaded into the client page and one iframe to handle key purchases. Because the key purchase iframe is lazy-loaded, most interactions with a locked page don't need to download it at all.</p>
<h2>Too Many Network Requests</h2>
<p>Previously, our application did a lot of polling to various places to maintain an accurate picture of a member's status. Over time we've managed to shrink this dramatically by choosing more carefully what information we really need for a good checkout experience, and being more clever about how to get that subset of data. This has been an ongoing process for some time now, but it culminates in the latest paywall release which prunes some of the chattiest parts of the application.</p>
<h2>Too Many Dependencies</h2>
<p>We previously used a library to handle Web3 calls on the paywall (to some extent we still do, but only in the lazy-loaded checkout iframe). We found that this library contributed some substantial weight to our application, when it was only being used for a handful of calls. We found that it wasn't hard for us to manually implement methods to make these calls to the chain, which saved us both time and space.</p>
<h1>Greater Capabilities With Less Code</h1>
<p>We've managed to make these changes without compromising the functionality of our paywall application at all. In fact, this rearchitecture made it possible to move more quickly while implementing new features that previously would have taken a lot more effort. The first and most visible update is a UI overhaul that takes up less space and works a lot better on mobile devices. We'll have more news on what's next in the pipeline in future blog posts.</p>
<h1>An Evergreen Deployment Model</h1>
<p>If you've integrated Unlock on your site before, you'll have noticed that you load the script <code>unlock.1.0.min.js</code>. So is today's announcement about <code>unlock.2.0.min.js</code>? Nope! Because we aren't making any breaking changes to the Paywall API and we want to ensure that consumers can smoothly and quickly get the latest and greatest code, we've moved to an explicitly "evergreen" model. Loading <code>unlock.latest.min.js</code> on your page will ensure that you're always up-to-date and get continuous improvements with every production deploy we do. <a href="https://docs.unlock-protocol.com">Our docs</a> have been updated to this effect.</p>



Some of you may have noticed a huge leap in our version numbers; the last release was v1.3 and now we've jumped to v7. Let me explain the reasoning for this. Since our first release, we've been using 2 different version numbering systems. We've followed semver standards in our published modules, but our smart-contracts (which can be queried for their current version) have used the type `uint` to store this value for simplicity. We've decided to make things more straightforward by using the `uint`-style versioning consistently, which means we don't need to map between 2 different systems internally. Moving forward, version numbers will simply increment each version. The name of the npm-module and the version number returned when querying our contracts for their version will be identical. We've just released v7 of our contracts, and so the newly published module has been cleverly named "unlock-abi-7".

## What's Changed

### Hooks

A feature common to many areas of programming, code hooks give us a way to extend the functionality of a smart contract to meet changing needs & new use-cases. We're adding 2 hooks with v7: A `KeyPurchaseHook` and a `KeyCancelHook`. These are included in the new npm module (`unlock-abi-7`) as interfaces, allowing a vast amount of flexibility in how they're implemented. A couple of example use-cases include adding custom cancellation logic, and adding support for discount codes!

### Support for direct ETH tips

We've modified the fallback function in the PublicLock contract to allow for tips (paid in ETH) to be sent directly to a Lock's address. This was previously not something we allowed. Before v7, `PublicLock.sol` contained a `destroyLock(...)` function which would invoke the built-in `selfdestruct` functionality. The decision to include this function was based on our desire to be good citizens of the ethereum ecosystem, allowing deprecated locks to be destroyed and free up space on the blockchain. Under these conditions, we didn't want anyone to be able to send eth to a Lock which had been self-destructed as these funds would be unrecoverable.
However, it is now generally considered somewhat of an antipattern to use `selfdestruct` in a contract. This is not to say there are no valid use-cases, but for us, the security concerns outweighed the potential benefits and we made the call to remove `selfdestruct` from v7. With this change, there is no reason to block direct eth transfers to a lock anymore, so feel free to tip your creators and show your appreciation!

### Access-Control

We've been using the Ownable pattern for access control since the beginning of the project. If you're not familiar with this, it is often implemented by inheriting from openzeppelin's `Ownable.sol` contract, which gives us some basic functionality to control who may access certain functionality in the derived contract. It works and is probably the simplest way to get started when beginning a project (which is why it's used so often).
As is often the case with the simplest solution, it has its limitations. The main one for us at Unlock is that the Ownable pattern doesn't provide granular control of access. For this reason, we've migrated to using a more role-based access control system (RBAC), based on another openzeppelin contract `Roles.sol`. We're introducing LockManagers, KeyGranters and KeyManagers with v7. We'll be updating our docs in more detail around these changes, but here's an overview.

- LockManagers: This is a new role we've added to replace `owner`. The lock creator becomes the only LockManager by default, granting them the highest level of permissions for their lock. Unlike `owner`, there may be more than 1 LockManager.

* KeyGranters: Also implemented as a role, the lock creator is also the default KeyGranter.The primary reason for this role is to support additional purchase mechanisms beyond direct key purchases (think credit-card purchases, where a user pays Unlock with a credit card, Unlock buys the key from the lock, and then grants it to the user).

- KeyManagers: This is not a role in the same way the previous 2 are. It is more of an internal "title" assigned to a user, and there can only be 1 key manager per key. Only the key manager is authorized to transfer, share or cancel keys, and may or may not be the same entity as the key owner depending on how the key was originally acquired. This enables new use cases, such as the ability to "loan" your key to someone temporarily, while retaining the right to take it back when/if needed, or possibly putting keys (NFTs) inside of a vault contract as collateral by retaining ownership, but transfering the keyManager role to the vault itself!

### General Improvements

One of the underlying themes for this release has been to simplify where possible. On this front, we've moved to Solidity 0.5.17, fixed some minor bugs & compiler warnings, merged similar functions, updated & extended documentation, merged a couple of sub-contracts(Mixins), and added, fixed and refactored several tests.

Overall we think it's a great release with many improvements for internal developers, lock creators and external developers wanting to integrate locks onto their products. We hope you like it and feel free to check out the [code](https://github.com/unlock-protocol/unlock/) anytime!


V7 focuses on adding new features, revamping our access-control system, & general improvements to the codebase.

Improvements to the Unlock-Protocol

Smart Contract Upgrade: Version 7

<p>Some of you may have noticed a huge leap in our version numbers; the last release was v1.3 and now we've jumped to v7. Let me explain the reasoning for this. Since our first release, we've been using 2 different version numbering systems. We've followed semver standards in our published modules, but our smart-contracts (which can be queried for their current version) have used the type <code>uint</code> to store this value for simplicity. We've decided to make things more straightforward by using the <code>uint</code>-style versioning consistently, which means we don't need to map between 2 different systems internally. Moving forward, version numbers will simply increment each version. The name of the npm-module and the version number returned when querying our contracts for their version will be identical. We've just released v7 of our contracts, and so the newly published module has been cleverly named "unlock-abi-7".</p>
<h2>What's Changed</h2>
<h3>Hooks</h3>
<p>A feature common to many areas of programming, code hooks give us a way to extend the functionality of a smart contract to meet changing needs &#x26; new use-cases. We're adding 2 hooks with v7: A <code>KeyPurchaseHook</code> and a <code>KeyCancelHook</code>. These are included in the new npm module (<code>unlock-abi-7</code>) as interfaces, allowing a vast amount of flexibility in how they're implemented. A couple of example use-cases include adding custom cancellation logic, and adding support for discount codes!</p>
<h3>Support for direct ETH tips</h3>
<p>We've modified the fallback function in the PublicLock contract to allow for tips (paid in ETH) to be sent directly to a Lock's address. This was previously not something we allowed. Before v7, <code>PublicLock.sol</code> contained a <code>destroyLock(...)</code> function which would invoke the built-in <code>selfdestruct</code> functionality. The decision to include this function was based on our desire to be good citizens of the ethereum ecosystem, allowing deprecated locks to be destroyed and free up space on the blockchain. Under these conditions, we didn't want anyone to be able to send eth to a Lock which had been self-destructed as these funds would be unrecoverable.
However, it is now generally considered somewhat of an antipattern to use <code>selfdestruct</code> in a contract. This is not to say there are no valid use-cases, but for us, the security concerns outweighed the potential benefits and we made the call to remove <code>selfdestruct</code> from v7. With this change, there is no reason to block direct eth transfers to a lock anymore, so feel free to tip your creators and show your appreciation!</p>
<h3>Access-Control</h3>
<p>We've been using the Ownable pattern for access control since the beginning of the project. If you're not familiar with this, it is often implemented by inheriting from openzeppelin's <code>Ownable.sol</code> contract, which gives us some basic functionality to control who may access certain functionality in the derived contract. It works and is probably the simplest way to get started when beginning a project (which is why it's used so often).
As is often the case with the simplest solution, it has its limitations. The main one for us at Unlock is that the Ownable pattern doesn't provide granular control of access. For this reason, we've migrated to using a more role-based access control system (RBAC), based on another openzeppelin contract <code>Roles.sol</code>. We're introducing LockManagers, KeyGranters and KeyManagers with v7. We'll be updating our docs in more detail around these changes, but here's an overview.</p>
<ul>
<li>LockManagers: This is a new role we've added to replace <code>owner</code>. The lock creator becomes the only LockManager by default, granting them the highest level of permissions for their lock. Unlike <code>owner</code>, there may be more than 1 LockManager.</li>
</ul>
<ul>
<li>KeyGranters: Also implemented as a role, the lock creator is also the default KeyGranter.The primary reason for this role is to support additional purchase mechanisms beyond direct key purchases (think credit-card purchases, where a user pays Unlock with a credit card, Unlock buys the key from the lock, and then grants it to the user).</li>
</ul>
<ul>
<li>KeyManagers: This is not a role in the same way the previous 2 are. It is more of an internal "title" assigned to a user, and there can only be 1 key manager per key. Only the key manager is authorized to transfer, share or cancel keys, and may or may not be the same entity as the key owner depending on how the key was originally acquired. This enables new use cases, such as the ability to "loan" your key to someone temporarily, while retaining the right to take it back when/if needed, or possibly putting keys (NFTs) inside of a vault contract as collateral by retaining ownership, but transfering the keyManager role to the vault itself!</li>
</ul>
<h3>General Improvements</h3>
<p>One of the underlying themes for this release has been to simplify where possible. On this front, we've moved to Solidity 0.5.17, fixed some minor bugs &#x26; compiler warnings, merged similar functions, updated &#x26; extended documentation, merged a couple of sub-contracts(Mixins), and added, fixed and refactored several tests.</p>
<p>Overall we think it's a great release with many improvements for internal developers, lock creators and external developers wanting to integrate locks onto their products. We hope you like it and feel free to check out the <a href="https://github.com/unlock-protocol/unlock/">code</a> anytime!</p>
