
# 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>



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