
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>



As part of its CDN architecture, [Cloudflare](https://cloudflare.com) recently introduced the concept of "[Workers](https://workers.cloudflare.com/)"... These are lambda functions which get executed on every requests going through Cloudflare's CDN. It's very similar to the **middleware architecture** popularized in several HTTP frameworks such as ruby's [Rack](https://github.com/rack/rack) or Node.js's Express.

A Worker can be used to alter a request or a response, or even completely rewrite these. Their [boilerplate section](https://developers.cloudflare.com/workers/templates) shows several interesting use cases which can be added to your website or application today.

# Token gating with a lock

As the web is [moving away from ads as its only business model](https://medium.com/unlock-protocol/the-end-of-the-ad-supported-web-d4d093fb462f), many websites are adding paywalls or other kinds of memberships to restrict access to some content or features. _Unfortunately, from a developer perspective, adding a a membership to a website is non-trivial_. Publishers have to first add a database of user accounts, then, they have to add mechanisms to collect payments, and finally they have to add logic to each of their webpage to enforce access control.

This amount of work not only takes times and resources, but often, it is not even not compatible with some other architectural constraints: static sites for examples, cannot implement this kind of access control... Similarly, for end users, a web where users have to create accounts with every single web site is only going to mean that we'll user even fewer websites: the friction would be just too high.

## Inroducing the Unlock Cloudflare Worker!

By now, you know that Unlock is a **protocol for memberships** as NFT. It _decouples_ the membership itself from the website to which these memberships apply. This means that the website does not have to implement mechanisms itself to enforce access control, as they can be implemented at a different layer, and the CDN is actually a great place to do this, with the help of the [Unlock Cloudflare Worker](https://github.com/unlock-protocol/cloudflare-worker)!

### How to token-gate a website with Cloudflare

#### Clone the repo:

```bash
git clone git@github.com:unlock-protocol/cloudflare-worker.git
```

#### Configure worker

Update its `.src/config.js` file to match your needs. Importantly, you need to keep the `pessimistic` mode to be `true` .

#### Install dependencies

```bash
yarn
```

#### Push to cloudflare

```bash
yarn wrangler publish
```

(You will likely be prompted to login to CloudFlare first)

#### Configure website

Now that the worker is deployed, you need to link it to your CloudFlare sites. Your mileage may vary but here is howe we did it for https://token-gated.com. From the Cloudflare Dashboard, select your website, in the left column, click on "Workers". Click the `Add Route` button. Enter the route(s) you want to "token-gate". In the `Service` select, pick the `unlock-cloudflare-worker` and select the environment of choice. Hit `Save`. You're all set!

![Screen Recording 2022-02-05 at 05 38 31 PM](https://user-images.githubusercontent.com/17735/152661436-347c9ccf-a9fb-4d1e-8b3a-817ecfb2a887.gif)

# Closing thoughts

Our approach in this example is fairly brute-force: every request to a domain is intercepted by our worker and,
the content is locked unless the visitor is a member. One could easily implement other kinds of locking,
maybe by rewriting the CSS files and enabling a completely different version of the website. Another option would be to automatically remove all ads from the content if the user is a member... etc. You could easily lock video content as well, by rendering a preview video, rather than the full version.

> Since Unlock **supports credit cards**, using an Unlock Worker is the simplest way to start monetizing your content for anyone on the web!

The [web is an operating system](https://unlock-protocol.com/blog/access-control-primitive/), Unlock is its access control layer, and Cloudflare, as a middleware is the perfect place to implement it!

PS: to the Workers team at Cloudflare: thank you... and maybe one feature request: please let workers creators like us "package" our workers so that they can be installed and configured from inside of the Cloudflare UI by other website owners!


Cloudflare is a leading Content Delivery Network provider. Web sites and application can use Cloudflare to add a layer between consumers and their applications in order to increase delivery speed, reduce the impact of attacks... or, add an Unlock lock!

Or, how to put a lock on any website without changing its code!

The Unlock Cloudflare Worker

<p>As part of its CDN architecture, <a href="https://cloudflare.com">Cloudflare</a> recently introduced the concept of "<a href="https://workers.cloudflare.com/">Workers</a>"... These are lambda functions which get executed on every requests going through Cloudflare's CDN. It's very similar to the <strong>middleware architecture</strong> popularized in several HTTP frameworks such as ruby's <a href="https://github.com/rack/rack">Rack</a> or Node.js's Express.</p>
<p>A Worker can be used to alter a request or a response, or even completely rewrite these. Their <a href="https://developers.cloudflare.com/workers/templates">boilerplate section</a> shows several interesting use cases which can be added to your website or application today.</p>
<h1>Token gating with a lock</h1>
<p>As the web is <a href="https://medium.com/unlock-protocol/the-end-of-the-ad-supported-web-d4d093fb462f">moving away from ads as its only business model</a>, many websites are adding paywalls or other kinds of memberships to restrict access to some content or features. <em>Unfortunately, from a developer perspective, adding a a membership to a website is non-trivial</em>. Publishers have to first add a database of user accounts, then, they have to add mechanisms to collect payments, and finally they have to add logic to each of their webpage to enforce access control.</p>
<p>This amount of work not only takes times and resources, but often, it is not even not compatible with some other architectural constraints: static sites for examples, cannot implement this kind of access control... Similarly, for end users, a web where users have to create accounts with every single web site is only going to mean that we'll user even fewer websites: the friction would be just too high.</p>
<h2>Inroducing the Unlock Cloudflare Worker!</h2>
<p>By now, you know that Unlock is a <strong>protocol for memberships</strong> as NFT. It <em>decouples</em> the membership itself from the website to which these memberships apply. This means that the website does not have to implement mechanisms itself to enforce access control, as they can be implemented at a different layer, and the CDN is actually a great place to do this, with the help of the <a href="https://github.com/unlock-protocol/cloudflare-worker">Unlock Cloudflare Worker</a>!</p>
<h3>How to token-gate a website with Cloudflare</h3>
<h4>Clone the repo:</h4>
<pre><code class="language-bash">git clone git@github.com:unlock-protocol/cloudflare-worker.git
</code></pre>
<h4>Configure worker</h4>
<p>Update its <code>.src/config.js</code> file to match your needs. Importantly, you need to keep the <code>pessimistic</code> mode to be <code>true</code> .</p>
<h4>Install dependencies</h4>
<pre><code class="language-bash">yarn
</code></pre>
<h4>Push to cloudflare</h4>
<pre><code class="language-bash">yarn wrangler publish
</code></pre>
<p>(You will likely be prompted to login to CloudFlare first)</p>
<h4>Configure website</h4>
<p>Now that the worker is deployed, you need to link it to your CloudFlare sites. Your mileage may vary but here is howe we did it for https://token-gated.com. From the Cloudflare Dashboard, select your website, in the left column, click on "Workers". Click the <code>Add Route</code> button. Enter the route(s) you want to "token-gate". In the <code>Service</code> select, pick the <code>unlock-cloudflare-worker</code> and select the environment of choice. Hit <code>Save</code>. You're all set!</p>
<p><img src="https://user-images.githubusercontent.com/17735/152661436-347c9ccf-a9fb-4d1e-8b3a-817ecfb2a887.gif" alt="Screen Recording 2022-02-05 at 05 38 31 PM"></p>
<h1>Closing thoughts</h1>
<p>Our approach in this example is fairly brute-force: every request to a domain is intercepted by our worker and,
the content is locked unless the visitor is a member. One could easily implement other kinds of locking,
maybe by rewriting the CSS files and enabling a completely different version of the website. Another option would be to automatically remove all ads from the content if the user is a member... etc. You could easily lock video content as well, by rendering a preview video, rather than the full version.</p>
<blockquote>
<p>Since Unlock <strong>supports credit cards</strong>, using an Unlock Worker is the simplest way to start monetizing your content for anyone on the web!</p>
</blockquote>
<p>The <a href="https://unlock-protocol.com/blog/access-control-primitive/">web is an operating system</a>, Unlock is its access control layer, and Cloudflare, as a middleware is the perfect place to implement it!</p>
<p>PS: to the Workers team at Cloudflare: thank you... and maybe one feature request: please let workers creators like us "package" our workers so that they can be installed and configured from inside of the Cloudflare UI by other website owners!</p>



[Glitch](https://glitch.com/) is a modern web development tool wich lets you build fast, full-stack web apps in your browser. It's not only a developer tool which can prove very useful for prototyping applications very fast, but can also be used to actually host these applications.

In this article, I will show you how to easily add a lock to a Glitch application to monetize it! First, [try the application](https://unlock-example.glitch.me/), or check the embedded version below! You can click on the Fishes in the top right corner to <em>View Source</em> or <em>Remix on Glitch</em>, if you want to edit the code (it's a great way to start building your own application!).

<div class="glitch-embed-wrap" style="height: 486px; width: 100%; margin-bottom: 50px">
  <iframe
    allow="geolocation; microphone; camera; midi; encrypted-media"
    src="https://glitch.com/embed/#!/embed/unlock-example?previewSize=100&previewFirst=true&sidebarCollapsed=true"
    alt="unlock-example on Glitch"
    style="height: 100%; width: 100%; border: 0;">
  </iframe>
</div>

Let's start by clicking on the **View Source** button. Use the little ▶️ button in the top right corner to view the list of files. Our application is very trivial and includes the following files `index.html`, `index.js`, `style.css` and `unlock.js`.

# Index.html

The `index.html` file includes the markup which is displayed by the web browser, as well as "loads" the other relevant files, such as the styles from the `style.css` file and the JavaScript code from both `index.js` and `unlock.js`.

The markup on the page includes 3 important elements. They all have the class `unlock-protocol`. We will use this class in our script to identify what needs to be shown or hidden based on the status of the visitor (member or not!).

1. The first paragraph with the class `loading` acts as a placeholder and it will only be visible while the rest of the page is being loaded.

```
<p class="unlock-protocol loading">
  Loading!
</p>
```

2. The second paragraph is hidden by default (see `style="display:none"`), and has the class `unlocked`. This one will be only shown when the visitor is a member.

```
<p class="unlock-protocol unlocked" style="display:none">
  Thanks for being a member ;)
</p>
```

3. The 3rd paragraph is also hidden by default, but this time it has the class `locked`, which means it will be shown when the visitor is not a member. That's in this paragraph that we will add a button for the user to purchase their membership, through the `unlockProtocol.loadCheckoutModal()` method.

```
<p class="unlock-protocol locked" style="display:none">
  <button onclick="window.unlockProtocol.loadCheckoutModal()">
    Please, become a member now!
  </button>
</p>
```

# Unlock.js

Let's now look at the `unlock.js` script. This script has several purposes:

1. It loads the unlock paywall application

```
// Load Unlock
var js = document.createElement("script")
sc = document.getElementsByTagName("script")[0]
js.src="https://paywall.unlock-protocol.com/unlock.latest.min.js"
sc.parentNode.insertBefore(js, sc)
```

2. It configures the behavior of the paywall application

```
// Configure Unlock
var unlockProtocolConfig = {
  locks: {
    '0xb77030a7e47a5eb942a4748000125e70be598632': {
      network: 137,
    },
  },
}
```

3. And finally, it handles the events to show or hide elements based on the state of the visitor. By default, it hides all elements with the `unlock-protocol` class, and just shows the ones which are relevant to the event which was emitted.

```
// Handle unlock events to hide/show element based on state
window.addEventListener('unlockProtocol', function(e) {
  var state = e.detail

  document.querySelectorAll('.unlock-protocol').forEach((element) => {
    element.style.display = 'none';
  })
  document.querySelectorAll(`.${state}`).forEach((element) => {
    element.style.display = 'block';
  })
})
```

That's it!

# What are you building?

Unlock should be a very small part of any application because it is just about _access control_. What your application grants to users is completely up to you! Here are a few applications which you might be interested in looking at:

- A [chat room application](https://ethcc-chat.glitch.me/) where only members can participate! I built this application for [EthCC](https://ethcc.io/) to show how easy to re-use a locks used to sell tickets in a different context!
- A [locked Typeform](https://locked-typeform.glitch.me/). Typeform is an application which lets you build surveys and forms. This example shows how you can build a way to collect information only from your members!

What would you build?


Glitch is a modern web development tool which lets you build fast, full-stack web apps in your browser. Here's how to add locks to these applications!

Locking Glitch

<p><a href="https://glitch.com/">Glitch</a> is a modern web development tool wich lets you build fast, full-stack web apps in your browser. It's not only a developer tool which can prove very useful for prototyping applications very fast, but can also be used to actually host these applications.</p>
<p>In this article, I will show you how to easily add a lock to a Glitch application to monetize it! First, <a href="https://unlock-example.glitch.me/">try the application</a>, or check the embedded version below! You can click on the Fishes in the top right corner to <em>View Source</em> or <em>Remix on Glitch</em>, if you want to edit the code (it's a great way to start building your own application!).</p>
<div class="glitch-embed-wrap" style="height: 486px; width: 100%; margin-bottom: 50px">
  <iframe
    allow="geolocation; microphone; camera; midi; encrypted-media"
    src="https://glitch.com/embed/#!/embed/unlock-example?previewSize=100&previewFirst=true&sidebarCollapsed=true"
    alt="unlock-example on Glitch"
    style="height: 100%; width: 100%; border: 0;">
  </iframe>
</div>
<p>Let's start by clicking on the <strong>View Source</strong> button. Use the little ▶️ button in the top right corner to view the list of files. Our application is very trivial and includes the following files <code>index.html</code>, <code>index.js</code>, <code>style.css</code> and <code>unlock.js</code>.</p>
<h1>Index.html</h1>
<p>The <code>index.html</code> file includes the markup which is displayed by the web browser, as well as "loads" the other relevant files, such as the styles from the <code>style.css</code> file and the JavaScript code from both <code>index.js</code> and <code>unlock.js</code>.</p>
<p>The markup on the page includes 3 important elements. They all have the class <code>unlock-protocol</code>. We will use this class in our script to identify what needs to be shown or hidden based on the status of the visitor (member or not!).</p>
<ol>
<li>The first paragraph with the class <code>loading</code> acts as a placeholder and it will only be visible while the rest of the page is being loaded.</li>
</ol>
<pre><code>&#x3C;p class="unlock-protocol loading">
  Loading!
&#x3C;/p>
</code></pre>
<ol start="2">
<li>The second paragraph is hidden by default (see <code>style="display:none"</code>), and has the class <code>unlocked</code>. This one will be only shown when the visitor is a member.</li>
</ol>
<pre><code>&#x3C;p class="unlock-protocol unlocked" style="display:none">
  Thanks for being a member ;)
&#x3C;/p>
</code></pre>
<ol start="3">
<li>The 3rd paragraph is also hidden by default, but this time it has the class <code>locked</code>, which means it will be shown when the visitor is not a member. That's in this paragraph that we will add a button for the user to purchase their membership, through the <code>unlockProtocol.loadCheckoutModal()</code> method.</li>
</ol>
<pre><code>&#x3C;p class="unlock-protocol locked" style="display:none">
  &#x3C;button onclick="window.unlockProtocol.loadCheckoutModal()">
    Please, become a member now!
  &#x3C;/button>
&#x3C;/p>
</code></pre>
<h1>Unlock.js</h1>
<p>Let's now look at the <code>unlock.js</code> script. This script has several purposes:</p>
<ol>
<li>It loads the unlock paywall application</li>
</ol>
<pre><code>// Load Unlock
var js = document.createElement("script")
sc = document.getElementsByTagName("script")[0]
js.src="https://paywall.unlock-protocol.com/unlock.latest.min.js"
sc.parentNode.insertBefore(js, sc)
</code></pre>
<ol start="2">
<li>It configures the behavior of the paywall application</li>
</ol>
<pre><code>// Configure Unlock
var unlockProtocolConfig = {
  locks: {
    '0xb77030a7e47a5eb942a4748000125e70be598632': {
      network: 137,
    },
  },
}
</code></pre>
<ol start="3">
<li>And finally, it handles the events to show or hide elements based on the state of the visitor. By default, it hides all elements with the <code>unlock-protocol</code> class, and just shows the ones which are relevant to the event which was emitted.</li>
</ol>
<pre><code>// Handle unlock events to hide/show element based on state
window.addEventListener('unlockProtocol', function(e) {
  var state = e.detail

  document.querySelectorAll('.unlock-protocol').forEach((element) => {
    element.style.display = 'none';
  })
  document.querySelectorAll(`.${state}`).forEach((element) => {
    element.style.display = 'block';
  })
})
</code></pre>
<p>That's it!</p>
<h1>What are you building?</h1>
<p>Unlock should be a very small part of any application because it is just about <em>access control</em>. What your application grants to users is completely up to you! Here are a few applications which you might be interested in looking at:</p>
<ul>
<li>A <a href="https://ethcc-chat.glitch.me/">chat room application</a> where only members can participate! I built this application for <a href="https://ethcc.io/">EthCC</a> to show how easy to re-use a locks used to sell tickets in a different context!</li>
<li>A <a href="https://locked-typeform.glitch.me/">locked Typeform</a>. Typeform is an application which lets you build surveys and forms. This example shows how you can build a way to collect information only from your members!</li>
</ul>
<p>What would you build?</p>



[Wikipedia says it best](https://en.wikipedia.org/wiki/Operating_system):

> An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.

As the Coronavirus is bringing the physical world to a halt through a denial of service attack on healthcare systems, it's increasingly obvious that the _virtual_ layer that we've been building for the last 40 years is acting as an **operating system for mankind**. As a system, Internet provides the underlying architecture upon which we communicate, work, collaborate, teach, learn, commerce and even have feelings.

## The Interet Operating System

Operating Systems provide a set of primitives which are used by applications running on that same operating system. Internet is not different. On the internet, these primitives take the form of **Protocols**!

For example, your computer (or phone!) has an addressing primitive. Do you remember when people talked about your `C:\` Drive? On the web, it's the job of the URL. The format of these URL is protocol which describes to web browsers how to access a file.

Another example is _identity_. Computers have "accounts". On the web, this identity layer is now mostly controlled by Google and Facebook... In the blockchain world, public-key cryptography provides that layer. On top of the identity layer, sits an authentication layer. On the web, this time, the [OAuth](https://en.wikipedia.org/wiki/OAuth) protocol enables internet users to login on a website with their identity from another website. It's a great experience because it reduces the need to create accounts (and remember passwords) on every single website.

Internet is of course, powered by dozens of protocols. Do you know about `TCP`, `HTTP`, `FTP`, `XMPP`, `WebSub`, `IPFS`, `NTP`, `IMAP`, `DNS` or `Bitcoin`? What about `IRC`, `SSH`, `MQTT`, `DHCP`, `SIP`, `POP`, `SMTP`?... They all have a distinct purposes.

# Access Control

As we've seen above _identity is a core primitive of any operating system_, including Internet. It is critical to another very important primitive called **Access Control**. _This primitive enforces which user gets access to what resources inside of the Operating System._

For example, on a computer or a server, when a user creates a file, they can determine which other user can access it. Each application has a set of users who can run it... etc.

> On the internet, the access control layer is critical, because access control represents an opportunity for monetization, [away from attention](https://medium.com/unlock-protocol/the-end-of-the-ad-supported-web-d4d093fb462f).

Each creator, whether they [compose music](http://phunkstatik.zplit.eth.link/), [record videos](https://chrisblec.com/CHAI/), [write content](https://bit.ly/the-defiant) or software should be able to decide the terms for access, including the price of a membership, the duration of a membership, or even the number of members!

It is already happening: Google, Facebook, Apple and Amazon **already own identities** and the logical next step is to own access control. Apple made the first move with the AppStore, and later, Apple Pay. Google follows very closely. As more and more people get online and purchase access to content or software, these 2 companies increasingly act as gatekeepers. Creators don't decide of the terms: Apple and Google do. It's pretty clear that Facebook and Amazon are pursuing similar strategies, the first by building Libra, a currency for the internet, and the second one by owning more and more of the internet's underlying architecture, including users' wallets.

At Unlock, we strongly believe that a _healthy web is one where creators are rewarded by their fans_, not through them. We also believe that the web needs to be decentralized to remain useful: permissionless innovation has been the main driver of progress and we do not want to accept a world where a few tech companies decide what content is "worth" being produced, distributed or even monetized!


The web is an operating system. Unlock Protocol is its access control primitive

The Access Control Primitive

<p><a href="https://en.wikipedia.org/wiki/Operating_system">Wikipedia says it best</a>:</p>
<blockquote>
<p>An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.</p>
</blockquote>
<p>As the Coronavirus is bringing the physical world to a halt through a denial of service attack on healthcare systems, it's increasingly obvious that the <em>virtual</em> layer that we've been building for the last 40 years is acting as an <strong>operating system for mankind</strong>. As a system, Internet provides the underlying architecture upon which we communicate, work, collaborate, teach, learn, commerce and even have feelings.</p>
<h2>The Interet Operating System</h2>
<p>Operating Systems provide a set of primitives which are used by applications running on that same operating system. Internet is not different. On the internet, these primitives take the form of <strong>Protocols</strong>!</p>
<p>For example, your computer (or phone!) has an addressing primitive. Do you remember when people talked about your <code>C:\</code> Drive? On the web, it's the job of the URL. The format of these URL is protocol which describes to web browsers how to access a file.</p>
<p>Another example is <em>identity</em>. Computers have "accounts". On the web, this identity layer is now mostly controlled by Google and Facebook... In the blockchain world, public-key cryptography provides that layer. On top of the identity layer, sits an authentication layer. On the web, this time, the <a href="https://en.wikipedia.org/wiki/OAuth">OAuth</a> protocol enables internet users to login on a website with their identity from another website. It's a great experience because it reduces the need to create accounts (and remember passwords) on every single website.</p>
<p>Internet is of course, powered by dozens of protocols. Do you know about <code>TCP</code>, <code>HTTP</code>, <code>FTP</code>, <code>XMPP</code>, <code>WebSub</code>, <code>IPFS</code>, <code>NTP</code>, <code>IMAP</code>, <code>DNS</code> or <code>Bitcoin</code>? What about <code>IRC</code>, <code>SSH</code>, <code>MQTT</code>, <code>DHCP</code>, <code>SIP</code>, <code>POP</code>, <code>SMTP</code>?... They all have a distinct purposes.</p>
<h1>Access Control</h1>
<p>As we've seen above <em>identity is a core primitive of any operating system</em>, including Internet. It is critical to another very important primitive called <strong>Access Control</strong>. <em>This primitive enforces which user gets access to what resources inside of the Operating System.</em></p>
<p>For example, on a computer or a server, when a user creates a file, they can determine which other user can access it. Each application has a set of users who can run it... etc.</p>
<blockquote>
<p>On the internet, the access control layer is critical, because access control represents an opportunity for monetization, <a href="https://medium.com/unlock-protocol/the-end-of-the-ad-supported-web-d4d093fb462f">away from attention</a>.</p>
</blockquote>
<p>Each creator, whether they <a href="http://phunkstatik.zplit.eth.link/">compose music</a>, <a href="https://chrisblec.com/CHAI/">record videos</a>, <a href="https://bit.ly/the-defiant">write content</a> or software should be able to decide the terms for access, including the price of a membership, the duration of a membership, or even the number of members!</p>
<p>It is already happening: Google, Facebook, Apple and Amazon <strong>already own identities</strong> and the logical next step is to own access control. Apple made the first move with the AppStore, and later, Apple Pay. Google follows very closely. As more and more people get online and purchase access to content or software, these 2 companies increasingly act as gatekeepers. Creators don't decide of the terms: Apple and Google do. It's pretty clear that Facebook and Amazon are pursuing similar strategies, the first by building Libra, a currency for the internet, and the second one by owning more and more of the internet's underlying architecture, including users' wallets.</p>
<p>At Unlock, we strongly believe that a <em>healthy web is one where creators are rewarded by their fans</em>, not through them. We also believe that the web needs to be decentralized to remain useful: permissionless innovation has been the main driver of progress and we do not want to accept a world where a few tech companies decide what content is "worth" being produced, distributed or even monetized!</p>



### What it is

Unlock is a protocol which enables creators to monetize their content with a few lines of code in a fully decentralized way, enabling programmable access to resources. This could include a blog, a subset of software features, or an event.

The core of the protocol is built on ethereum, and is enabled by 2 primary smart contracts, `Unlock.sol` & `PublicLock.sol`.

- `Unlock.sol` is the factory contract. it deploys locks for creators and is responsible for managing network-wide functionality such as granting discounts and tracking the GNP of the network. This contract is upgradeable.

- `Publiclock.sol` is the lock contract. These are deployed by the factory when a creator creates a new lock. We don't actually deploy the full lock contract for each lock. This would be very heavy, as `PublicLock.sol` is a large contract. (To get an idea of the size, when flattened it's about 3,470 lines of code). Instead, we make use of eip-1167 (minimal proxies) to deploy lightweight proxy-clones for each lock. The logic for these clones is determined by a single deployed `PublicLock.sol` which acts as the template for all locks.

### How we use OpenZeppelin

We make use of a number of the tools & libraries that OZ offers:

#### Upgradeability

At Unlock, our approach to upgradeability has been to make the factory contract(`Unlock.sol`) upgradeable to enable us to continue to add and refine features. Since launching, we've had many requests from users to add support for new use-cases and without upgrades, this just wouldn't be feasible. However, the Lock contracts deployed from this factory are NOT upgradeable. This gives lock creators assurance that their lock is theirs forever, and can't be changed by anyone.
While there's no shortage of debate over the very idea of upgradeable contracts in the industry, one thing is very clear; the Openzeppelin-SDK makes it super-easy to manage and track upgrades! We manage most contract deployments and upgrades of `Unlock.sol` with openzeppelin's cli and appreciate the way the "network files" (ie: `/.openzeppelin/mainnet.json`) help us to keep track of the deployed contract addresses, current implementations, etc. Also, the ability to deploy contracts and then query them or submit tx's easily all via the cli is nice, avoiding the need to jump back and forth between many different toolsets to achieve the same.

#### Library

We use a number of openzeppelin's contracts from `@openzeppelin/upgrades/`, `@openzeppelin/contracts/`, and `@openzeppelin/contracts-ethereum-package/`. These include:

- `Initializable.sol`
- `IERC1820Registry.sol`
- `ECDSA.sol`
- `Address.sol`
- `Ownable.sol`
- `ERC165.sol`
- `IERC721Enumerable.sol`
- `IERC721Receiver.sol`
- `SafeMath.sol`
- `Roles.sol`
- `IERC20.sol`
- `SafeERC20.sol`

#### Test-Helpers

We've only just started to use some of the OZ test-helpers, but the experience so far has been great. For those who haven't tried them, they make a lot of common, repetitive tasks in testing very straightforward, and I highly recommend at least checking them out.

#### Access Control

We currently use `Ownable.sol` and the `onlyOwner` modifier extensively throughout our contracts. However, having realized some of the limitations/drawbacks of this approach, we've been re-evaluating our approach to access control and are migrating to a predominantly role-based approach using OZ's `Roles.sol`. At the moment it seems that the current approach to this topic is being revamped by OZ, so we're watching to see what emerges and will have to reassess whether it still meets our needs.

### Links

To learn more or get in touch, feel free to reach out to the team, try out our dashboard on the rinkeby testnet, or just explore the code in our GitHub repo.

- Unlock-Protocol: [unlock-protocol.com](https://unlock-protocol.com/)
- Github: [github.com/unlock-protocol/unlock](https://github.com/unlock-protocol/unlock)
- Docs: [docs.unlock-protocol.com](https://docs.unlock-protocol.com/)
- Blog: [unlock-protocol.com/blog](https://unlock-protocol.com/blog/)
- twitter [twitter.com/UnlockProtocol](https://twitter.com/UnlockProtocol)
- discord: [discord.gg/Ah6ZEJyTDp](https://discord.gg/Ah6ZEJyTDp)
- email: hello@unlock-protocol.com


Openzeppelin provides the ethereum community an excellent assortment of reusable libraries and command-line tools. Here's how we use them at Unlock.

Showcasing our usage of open-source tools.

How we use OpenZeppelin

<h3>What it is</h3>
<p>Unlock is a protocol which enables creators to monetize their content with a few lines of code in a fully decentralized way, enabling programmable access to resources. This could include a blog, a subset of software features, or an event.</p>
<p>The core of the protocol is built on ethereum, and is enabled by 2 primary smart contracts, <code>Unlock.sol</code> &#x26; <code>PublicLock.sol</code>.</p>
<ul>
<li>
<p><code>Unlock.sol</code> is the factory contract. it deploys locks for creators and is responsible for managing network-wide functionality such as granting discounts and tracking the GNP of the network. This contract is upgradeable.</p>
</li>
<li>
<p><code>Publiclock.sol</code> is the lock contract. These are deployed by the factory when a creator creates a new lock. We don't actually deploy the full lock contract for each lock. This would be very heavy, as <code>PublicLock.sol</code> is a large contract. (To get an idea of the size, when flattened it's about 3,470 lines of code). Instead, we make use of eip-1167 (minimal proxies) to deploy lightweight proxy-clones for each lock. The logic for these clones is determined by a single deployed <code>PublicLock.sol</code> which acts as the template for all locks.</p>
</li>
</ul>
<h3>How we use OpenZeppelin</h3>
<p>We make use of a number of the tools &#x26; libraries that OZ offers:</p>
<h4>Upgradeability</h4>
<p>At Unlock, our approach to upgradeability has been to make the factory contract(<code>Unlock.sol</code>) upgradeable to enable us to continue to add and refine features. Since launching, we've had many requests from users to add support for new use-cases and without upgrades, this just wouldn't be feasible. However, the Lock contracts deployed from this factory are NOT upgradeable. This gives lock creators assurance that their lock is theirs forever, and can't be changed by anyone.
While there's no shortage of debate over the very idea of upgradeable contracts in the industry, one thing is very clear; the Openzeppelin-SDK makes it super-easy to manage and track upgrades! We manage most contract deployments and upgrades of <code>Unlock.sol</code> with openzeppelin's cli and appreciate the way the "network files" (ie: <code>/.openzeppelin/mainnet.json</code>) help us to keep track of the deployed contract addresses, current implementations, etc. Also, the ability to deploy contracts and then query them or submit tx's easily all via the cli is nice, avoiding the need to jump back and forth between many different toolsets to achieve the same.</p>
<h4>Library</h4>
<p>We use a number of openzeppelin's contracts from <code>@openzeppelin/upgrades/</code>, <code>@openzeppelin/contracts/</code>, and <code>@openzeppelin/contracts-ethereum-package/</code>. These include:</p>
<ul>
<li><code>Initializable.sol</code></li>
<li><code>IERC1820Registry.sol</code></li>
<li><code>ECDSA.sol</code></li>
<li><code>Address.sol</code></li>
<li><code>Ownable.sol</code></li>
<li><code>ERC165.sol</code></li>
<li><code>IERC721Enumerable.sol</code></li>
<li><code>IERC721Receiver.sol</code></li>
<li><code>SafeMath.sol</code></li>
<li><code>Roles.sol</code></li>
<li><code>IERC20.sol</code></li>
<li><code>SafeERC20.sol</code></li>
</ul>
<h4>Test-Helpers</h4>
<p>We've only just started to use some of the OZ test-helpers, but the experience so far has been great. For those who haven't tried them, they make a lot of common, repetitive tasks in testing very straightforward, and I highly recommend at least checking them out.</p>
<h4>Access Control</h4>
<p>We currently use <code>Ownable.sol</code> and the <code>onlyOwner</code> modifier extensively throughout our contracts. However, having realized some of the limitations/drawbacks of this approach, we've been re-evaluating our approach to access control and are migrating to a predominantly role-based approach using OZ's <code>Roles.sol</code>. At the moment it seems that the current approach to this topic is being revamped by OZ, so we're watching to see what emerges and will have to reassess whether it still meets our needs.</p>
<h3>Links</h3>
<p>To learn more or get in touch, feel free to reach out to the team, try out our dashboard on the rinkeby testnet, or just explore the code in our GitHub repo.</p>
<ul>
<li>Unlock-Protocol: <a href="https://unlock-protocol.com/">unlock-protocol.com</a></li>
<li>Github: <a href="https://github.com/unlock-protocol/unlock">github.com/unlock-protocol/unlock</a></li>
<li>Docs: <a href="https://docs.unlock-protocol.com/">docs.unlock-protocol.com</a></li>
<li>Blog: <a href="https://unlock-protocol.com/blog/">unlock-protocol.com/blog</a></li>
<li>twitter <a href="https://twitter.com/UnlockProtocol">twitter.com/UnlockProtocol</a></li>
<li>discord: <a href="https://discord.gg/Ah6ZEJyTDp">discord.gg/Ah6ZEJyTDp</a></li>
<li>email: hello@unlock-protocol.com</li>
</ul>



![Take it with you](/images/blog/portability/hero.jpg)

You’ve experienced this: You‘ve bought something (or just searched for it) and now you have ads for that or a similar item following you around. What’s happening is you have two services – the shop you bought from and the ad delivery network – that are talking to you but not each other, and that leads to a not so great user experience.

A similar thing happens for subscriptions and memberships. A concrete example: I listen to The Daily, a NYTimes podcast, every day on Spotify. Annoyingly I have to listen to quite a lengthy segment that’s trying to convince me to subscribe to the Times – even though I’m a subscriber already.

I can see a future where Spotify will check my ethereum wallet, see that I have the New York Times membership token and give me The Daily version for members without promotions. Maybe they will even create a version without ads and special content for long time or higher tier subscribers.

In that future I could take advantage of many other benefits and services based on my existing purchases and memberships. Event discounts for NYTimes or Spotify members? I just need to sign a message from my wallet that checks that my membership is valid without having to sign up or share any additional information. Bought the audio book on Amazon and the publisher offers the ebook for free on their site? Easy to verify your purchase, no need to login or share your Amazon data. You’re a New York WeWork member and are in Berlin? They can easily verify your membership and give you free or discounted access without having to look you up in their system. The blockchain let’s different services talk to each other, cross checking your memberships and purchases with minimal data sharing, if you allow it. Your purchase and membership tokens function as universal keys.

Want to do something like this? So does Unlock – we’d love to do it together.


Instead of ads following us around our access should.

What I’m Excited About: Portability

<p><img src="/images/blog/portability/hero.jpg" alt="Take it with you"></p>
<p>You’ve experienced this: You‘ve bought something (or just searched for it) and now you have ads for that or a similar item following you around. What’s happening is you have two services – the shop you bought from and the ad delivery network – that are talking to you but not each other, and that leads to a not so great user experience.</p>
<p>A similar thing happens for subscriptions and memberships. A concrete example: I listen to The Daily, a NYTimes podcast, every day on Spotify. Annoyingly I have to listen to quite a lengthy segment that’s trying to convince me to subscribe to the Times – even though I’m a subscriber already.</p>
<p>I can see a future where Spotify will check my ethereum wallet, see that I have the New York Times membership token and give me The Daily version for members without promotions. Maybe they will even create a version without ads and special content for long time or higher tier subscribers.</p>
<p>In that future I could take advantage of many other benefits and services based on my existing purchases and memberships. Event discounts for NYTimes or Spotify members? I just need to sign a message from my wallet that checks that my membership is valid without having to sign up or share any additional information. Bought the audio book on Amazon and the publisher offers the ebook for free on their site? Easy to verify your purchase, no need to login or share your Amazon data. You’re a New York WeWork member and are in Berlin? They can easily verify your membership and give you free or discounted access without having to look you up in their system. The blockchain let’s different services talk to each other, cross checking your memberships and purchases with minimal data sharing, if you allow it. Your purchase and membership tokens function as universal keys.</p>
<p>Want to do something like this? So does Unlock – we’d love to do it together.</p>



# Meeting the Needs of Our Users

Over the course of the past year, Unlock has powered [membership](/blog/tokenizing-memberships/) opportunities like [newsletter subscriptions](/blog/introducing-newsletter/), [event](/blog/ethwaterloo-tickets/) [tickets](/blog/ethcc-tickets/), and [ad-free experiences](/blog/forbes-in-the-news/). One thing we've heard from creators who own locks is that in some cases they need to gather information from key purchasers before they buy a key.

For example, a newsletter publisher may want to email updates to subscribers. We offered a way for newsletter publishers in particular to gather some information through our [newsletter subscription app](/blog/introducing-newsletter/), but there were some limitations to that approach. For starters, publishers could not host this experience within their own site. Further, they couldn't specify which information could be collected. For anyone who needed to collect more than just an email address (or ran something other than a newsletter), we needed another solution.

# Broader Availability of Metadata Collection

Today we're proud to announce an extension to our embeddable Paywall application which allows creators to specify a number of form fields which should be presented to the purchaser before the purchase transaction begins. The technology behind this is our metadata system which we've already used behind-the-scenes in a few places. If you're already familiar with our Paywall, you can learn how to add metadata to your existing configuration [here](https://docs.unlock-protocol.com/tools/paywall/collecting-metadata). For everyone else, the remainder of this post is a worked example.

# Collecting Information From Purchasers

## The Scenario

Consider a blog that allows anyone to read published articles, but offers a perk for paying members: they get early access to articles before they are published in the open. One way to implement this is to collect an email address from paying members, which will be used to notify them of a new article and link them to a private page.

## The Setup

We'll start with the recommended setup from our [getting started guide](https://docs.unlock-protocol.com/#configure-the-lock) with one addition: an array of metadata fields we'd like to collect.

```
var unlockProtocolConfig = {
  locks: {
    '0xEE9FE39966DF737eECa5920ABa975c283784Faf8: {
      name: 'A Lock'
    },
  },
  icon: 'https://staging-app.unlock-protocol.com/images/svg/default.svg',
  callToAction: {
    default: 'This content is locked. Pay with cryptocurrency to access it!',
    expired: 'This is what is shown when the user had a key which is now expired',
    pending: 'This is the message shown when the user sent a transaction to purchase a key which has not be confirmed yet',
    confirmed: 'This is the message shown when the user has a confirmed key',
    noWallet: 'This is the message shown when the user does not have a crypto wallet which is required...',
  },
  // This is the addition to the config!
  metadataInputs: [
    {
        name: 'First Name',
        type: 'text',
        required: true,
        public: true,
    },
    {
        name: 'Last Name',
        type: 'text',
        required: false,
    },
    {
        name: 'Email Address',
        type: 'email',
        required: true,
    },
  ],
}
```

As you can see, we're going to collect 3 pieces of information: a first name (required, public), a last name (optional, protected), and an email address (required, protected).

## The Checkout

Let's walk through the flow. Here's the page when first visited. The full content of the page is behind a lock (because this article isn't available to the public yet).

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/lockedPage.png" width="750px" alt="the locked page">
</p>

When a user clicks the "Join us" button, they first see the normal list of key purchase buttons.

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/preCheckout.png" width="750px" alt="the checkout modal">
</p>

Then when they click the purchase button, they see the metadata fields we specified in the config. Note that the required fields have an asterisk next to them, and the form will not submit until they are filled. The field type provided in the config also maps to the kind of `<input>` element, so the email address field will also undergo some validation before it is accepted.

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/unfilledForm.png" width="750px" alt="the unfilled form">
</p>

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/filledForm.png" width="750px" alt="the filled form">
</p>

After submitting the form, the user is prompted to sign a message. This way we can make sure that the only person who can save information for a given address is the person in charge of that address.

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/signatureRequest.png" width="750px" alt="the signature request">
</p>

Once they sign the message, the normal checkout flow continues and the user is asked to authorize the purchase transaction.

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/metamaskPurchase.png" width="750px" alt="the purchase request">
</p>

Now they have a key and have access to the article.

## But Wait, There's More

The other side of this process is from the creator's perspective. Our user has a key, and as part of the purchase they submitted information we can use to notify them of new articles.

From the Unlock dashboard, we can click the "Members" button on our lock, and that will take us to the following page:

<p style="text-align:center">
    <img src="/images/blog/metadata-collection/membersPage.png" width="750px" alt="the members page with metadata">
</p>

As you can see, it contains a list of all key holders on this lock, how long their key is valid for, and what metadata we have about them. In this case, we have a first name and an email address which are exactly the pieces we need for a mailing list. We only have one key holder right now, but in practice there may be many so the Members page provides a CSV export of the metadata for easier automated processing.


Lock owners can require information from key purchasers before the transaction is initiated.

Connecting lock owners and key holders

Collecting Metadata for a Purchase

<h1>Meeting the Needs of Our Users</h1>
<p>Over the course of the past year, Unlock has powered <a href="/blog/tokenizing-memberships/">membership</a> opportunities like <a href="/blog/introducing-newsletter/">newsletter subscriptions</a>, <a href="/blog/ethwaterloo-tickets/">event</a> <a href="/blog/ethcc-tickets/">tickets</a>, and <a href="/blog/forbes-in-the-news/">ad-free experiences</a>. One thing we've heard from creators who own locks is that in some cases they need to gather information from key purchasers before they buy a key.</p>
<p>For example, a newsletter publisher may want to email updates to subscribers. We offered a way for newsletter publishers in particular to gather some information through our <a href="/blog/introducing-newsletter/">newsletter subscription app</a>, but there were some limitations to that approach. For starters, publishers could not host this experience within their own site. Further, they couldn't specify which information could be collected. For anyone who needed to collect more than just an email address (or ran something other than a newsletter), we needed another solution.</p>
<h1>Broader Availability of Metadata Collection</h1>
<p>Today we're proud to announce an extension to our embeddable Paywall application which allows creators to specify a number of form fields which should be presented to the purchaser before the purchase transaction begins. The technology behind this is our metadata system which we've already used behind-the-scenes in a few places. If you're already familiar with our Paywall, you can learn how to add metadata to your existing configuration <a href="https://docs.unlock-protocol.com/tools/paywall/collecting-metadata">here</a>. For everyone else, the remainder of this post is a worked example.</p>
<h1>Collecting Information From Purchasers</h1>
<h2>The Scenario</h2>
<p>Consider a blog that allows anyone to read published articles, but offers a perk for paying members: they get early access to articles before they are published in the open. One way to implement this is to collect an email address from paying members, which will be used to notify them of a new article and link them to a private page.</p>
<h2>The Setup</h2>
<p>We'll start with the recommended setup from our <a href="https://docs.unlock-protocol.com/#configure-the-lock">getting started guide</a> with one addition: an array of metadata fields we'd like to collect.</p>
<pre><code>var unlockProtocolConfig = {
  locks: {
    '0xEE9FE39966DF737eECa5920ABa975c283784Faf8: {
      name: 'A Lock'
    },
  },
  icon: 'https://staging-app.unlock-protocol.com/images/svg/default.svg',
  callToAction: {
    default: 'This content is locked. Pay with cryptocurrency to access it!',
    expired: 'This is what is shown when the user had a key which is now expired',
    pending: 'This is the message shown when the user sent a transaction to purchase a key which has not be confirmed yet',
    confirmed: 'This is the message shown when the user has a confirmed key',
    noWallet: 'This is the message shown when the user does not have a crypto wallet which is required...',
  },
  // This is the addition to the config!
  metadataInputs: [
    {
        name: 'First Name',
        type: 'text',
        required: true,
        public: true,
    },
    {
        name: 'Last Name',
        type: 'text',
        required: false,
    },
    {
        name: 'Email Address',
        type: 'email',
        required: true,
    },
  ],
}
</code></pre>
<p>As you can see, we're going to collect 3 pieces of information: a first name (required, public), a last name (optional, protected), and an email address (required, protected).</p>
<h2>The Checkout</h2>
<p>Let's walk through the flow. Here's the page when first visited. The full content of the page is behind a lock (because this article isn't available to the public yet).</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/lockedPage.png" width="750px" alt="the locked page">
</p>
<p>When a user clicks the "Join us" button, they first see the normal list of key purchase buttons.</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/preCheckout.png" width="750px" alt="the checkout modal">
</p>
<p>Then when they click the purchase button, they see the metadata fields we specified in the config. Note that the required fields have an asterisk next to them, and the form will not submit until they are filled. The field type provided in the config also maps to the kind of <code>&#x3C;input></code> element, so the email address field will also undergo some validation before it is accepted.</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/unfilledForm.png" width="750px" alt="the unfilled form">
</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/filledForm.png" width="750px" alt="the filled form">
</p>
<p>After submitting the form, the user is prompted to sign a message. This way we can make sure that the only person who can save information for a given address is the person in charge of that address.</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/signatureRequest.png" width="750px" alt="the signature request">
</p>
<p>Once they sign the message, the normal checkout flow continues and the user is asked to authorize the purchase transaction.</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/metamaskPurchase.png" width="750px" alt="the purchase request">
</p>
<p>Now they have a key and have access to the article.</p>
<h2>But Wait, There's More</h2>
<p>The other side of this process is from the creator's perspective. Our user has a key, and as part of the purchase they submitted information we can use to notify them of new articles.</p>
<p>From the Unlock dashboard, we can click the "Members" button on our lock, and that will take us to the following page:</p>
<p style="text-align:center">
    <img src="/images/blog/metadata-collection/membersPage.png" width="750px" alt="the members page with metadata">
</p>
<p>As you can see, it contains a list of all key holders on this lock, how long their key is valid for, and what metadata we have about them. In this case, we have a first name and an email address which are exactly the pieces we need for a mailing list. We only have one key holder right now, but in practice there may be many so the Members page provides a CSV export of the metadata for easier automated processing.</p>



Unlock Protocol enables content creators to sell keys which are NFTs used to gain access, unlock features, and/or display support for the creator. The content creators choose the price and which currency they prefer. ETH is the native currency but the value is volatile. Many prefer to price things in USD by using an ERC-20 token such as DAI.

We need to make this easy for users.

If someone is holding ETH, don’t tell them to find an exchange to buy DAI first - not if we can do it for them. Similarly if they are holding SAI or USDC but the content creator asked for DAI - it should just work.

Composability on Ethereum has been a recent topic of discussion in the industry. A great example popping up are DEX aggregators - these can connect to several exchanges to ensure traders always get the most for their money. It got us thinking...

Buying an NFT isn’t really much different than swapping from BAT to DAI. So we are not really solving a new problem here. And we have great examples to learn from.

## What this means for users

We do not have a frontend yet, but it’s coming! Once the feature has been integrated, users will be presented options during checkout.

E.g. if the key costs $5, I could have the option to:

- Pay with ~5 DAI / SAI / USDC / USDT
- Pay with ~0.03 ETH
- Pay with ~25 BAT

Only options using tokens the user actually owns will be presented. So if the user does not have USDT, it will not be mentioned.

This helps to overcome one of the challenges users have today - [“there are just too many ERC-20 [token types]”](https://twitter.com/julien51/status/1222957379031117825).

## How it works

[swap-and-call](https://github.com/unlock-protocol/unlock/tree/master/smart-contract-extensions) has an implementation that’s very similar to the [1inch.exchange](https://etherscan.io/address/0x11111254369792b2Ca5d084aB5eEA397cA8fa48B#code) contract. It’s basically a batch transaction processor with a little logic before and after for this use case. It is not built for Unlock specifically and does not assume any specific DEX, this approach should work for many other use cases as well.

High level steps for a swapAndCall transaction:

- Collect tokens from the user using `transferFrom` (if spending tokens instead of ETH)
- Call one or more contracts (any contract, any method, and params may be included)
- Send any tokens remaining back to the user

For Unlock’s use case, the contract calls we make are:

- Approve Uniswap to `transferFrom` SwapAndCall (if spending tokens instead of ETH)
- Call Uniswap to swap from the source token into the token type needed to buy a key
- Approve the Lock to `transferFrom` the SwapAndCall contract (if the key is priced in tokens instead of ETH)
- Call purchase on the lock contract to acquire a key which is sent directly to the user

<p style="text-align:center">
	<img src="/images/blog/unlocking-smart-contracts/code.jpeg" width="400px" alt="Smart contracts">
</p>

Here’s [an example transaction](https://etherscan.io/tx/0x8c0e34bb009a13b4c35ba3bd6b96c6ed2b5807ac0e5da47f65350017b38f5450) where I use SwapAndCall to pay with ETH and buy a key priced at $1, in DAI.

I sent the transaction to SwapAndCall with 0.0056 ETH (~$1.02)

- SwapAndCall forwards the ETH with a call to Uniswap to swap for the exact amount of DAI required
- Uniswap sends DAI to the SwapAndCall contract and refunds the leftover ETH
- SwapAndCall calls `purchase` and the key is sent directly to the end-user
- SwapAndCall refunds the remaining 0.00009 ETH to the end-user

We are using [Uniswap](https://uniswap.exchange/swap) but this process would work with other exchanges such as [Kyber](https://kyber.network/) or [Oasis](https://oasis.app/). You could also use a DEX aggregator such as [1inch](https://1inch.exchange/), [0x](https://0x.org/api/), [Dex.ag](https://dex.ag/), or [ParaSwap](https://paraswap.io/#/).

## What’s next

The front-end of course. But there is another big feature we want to add -- meta-transactions! (see our [roadmap document](https://github.com/unlock-protocol/unlock/wiki/Roadmap) to learn more!)

Meta-transactions allow users to sign messages approving smart contract actions, instead of broadcasting transactions. This means they are not paying gas fees directly and do not need to have any ETH.

[DAI](https://etherscan.io/address/0x6b175474e89094c44da98b954eedeac495271d0f#code) is helping to push this forward with the inclusion of the `permit` feature. Combined with SwapAndCall meta-transactions users could buy keys with DAI, without ever owning any ETH.

Like always, [all of our code is open source](https://github.com/unlock-protocol/), and we take pull requests, as well as grant bounties to people who help us move forward!

Let's keep pushing for a better user-experience.


Calling contracts without having to get a specific ERC-20 token type first.

Simplifying spending on Ethereum

Swap and Call

<p>Unlock Protocol enables content creators to sell keys which are NFTs used to gain access, unlock features, and/or display support for the creator. The content creators choose the price and which currency they prefer. ETH is the native currency but the value is volatile. Many prefer to price things in USD by using an ERC-20 token such as DAI.</p>
<p>We need to make this easy for users.</p>
<p>If someone is holding ETH, don’t tell them to find an exchange to buy DAI first - not if we can do it for them. Similarly if they are holding SAI or USDC but the content creator asked for DAI - it should just work.</p>
<p>Composability on Ethereum has been a recent topic of discussion in the industry. A great example popping up are DEX aggregators - these can connect to several exchanges to ensure traders always get the most for their money. It got us thinking...</p>
<p>Buying an NFT isn’t really much different than swapping from BAT to DAI. So we are not really solving a new problem here. And we have great examples to learn from.</p>
<h2>What this means for users</h2>
<p>We do not have a frontend yet, but it’s coming! Once the feature has been integrated, users will be presented options during checkout.</p>
<p>E.g. if the key costs $5, I could have the option to:</p>
<ul>
<li>Pay with ~5 DAI / SAI / USDC / USDT</li>
<li>Pay with ~0.03 ETH</li>
<li>Pay with ~25 BAT</li>
</ul>
<p>Only options using tokens the user actually owns will be presented. So if the user does not have USDT, it will not be mentioned.</p>
<p>This helps to overcome one of the challenges users have today - <a href="https://twitter.com/julien51/status/1222957379031117825">“there are just too many ERC-20 [token types]”</a>.</p>
<h2>How it works</h2>
<p><a href="https://github.com/unlock-protocol/unlock/tree/master/smart-contract-extensions">swap-and-call</a> has an implementation that’s very similar to the <a href="https://etherscan.io/address/0x11111254369792b2Ca5d084aB5eEA397cA8fa48B#code">1inch.exchange</a> contract. It’s basically a batch transaction processor with a little logic before and after for this use case. It is not built for Unlock specifically and does not assume any specific DEX, this approach should work for many other use cases as well.</p>
<p>High level steps for a swapAndCall transaction:</p>
<ul>
<li>Collect tokens from the user using <code>transferFrom</code> (if spending tokens instead of ETH)</li>
<li>Call one or more contracts (any contract, any method, and params may be included)</li>
<li>Send any tokens remaining back to the user</li>
</ul>
<p>For Unlock’s use case, the contract calls we make are:</p>
<ul>
<li>Approve Uniswap to <code>transferFrom</code> SwapAndCall (if spending tokens instead of ETH)</li>
<li>Call Uniswap to swap from the source token into the token type needed to buy a key</li>
<li>Approve the Lock to <code>transferFrom</code> the SwapAndCall contract (if the key is priced in tokens instead of ETH)</li>
<li>Call purchase on the lock contract to acquire a key which is sent directly to the user</li>
</ul>
<p style="text-align:center">
	<img src="/images/blog/unlocking-smart-contracts/code.jpeg" width="400px" alt="Smart contracts">
</p>
<p>Here’s <a href="https://etherscan.io/tx/0x8c0e34bb009a13b4c35ba3bd6b96c6ed2b5807ac0e5da47f65350017b38f5450">an example transaction</a> where I use SwapAndCall to pay with ETH and buy a key priced at $1, in DAI.</p>
<p>I sent the transaction to SwapAndCall with 0.0056 ETH (~$1.02)</p>
<ul>
<li>SwapAndCall forwards the ETH with a call to Uniswap to swap for the exact amount of DAI required</li>
<li>Uniswap sends DAI to the SwapAndCall contract and refunds the leftover ETH</li>
<li>SwapAndCall calls <code>purchase</code> and the key is sent directly to the end-user</li>
<li>SwapAndCall refunds the remaining 0.00009 ETH to the end-user</li>
</ul>
<p>We are using <a href="https://uniswap.exchange/swap">Uniswap</a> but this process would work with other exchanges such as <a href="https://kyber.network/">Kyber</a> or <a href="https://oasis.app/">Oasis</a>. You could also use a DEX aggregator such as <a href="https://1inch.exchange/">1inch</a>, <a href="https://0x.org/api/">0x</a>, <a href="https://dex.ag/">Dex.ag</a>, or <a href="https://paraswap.io/#/">ParaSwap</a>.</p>
<h2>What’s next</h2>
<p>The front-end of course. But there is another big feature we want to add -- meta-transactions! (see our <a href="https://github.com/unlock-protocol/unlock/wiki/Roadmap">roadmap document</a> to learn more!)</p>
<p>Meta-transactions allow users to sign messages approving smart contract actions, instead of broadcasting transactions. This means they are not paying gas fees directly and do not need to have any ETH.</p>
<p><a href="https://etherscan.io/address/0x6b175474e89094c44da98b954eedeac495271d0f#code">DAI</a> is helping to push this forward with the inclusion of the <code>permit</code> feature. Combined with SwapAndCall meta-transactions users could buy keys with DAI, without ever owning any ETH.</p>
<p>Like always, <a href="https://github.com/unlock-protocol/">all of our code is open source</a>, and we take pull requests, as well as grant bounties to people who help us move forward!</p>
<p>Let's keep pushing for a better user-experience.</p>
