
As transaction costs on Ethereum's mainnet keep sky-rocketing (it's a good thing!), like many other projects in the web3 space, we are exploring ways to provide a seamless experience in the Ethereum ecosystem, without the costs associated with a blockchain used heavily for large-value transactions. A few weeks ago, we launch the [Unlock Protocol on xDAI](/blog/xdai) and we're working on several more.

Unfortunately, there is a cost to using multiple chains: complexity for users. We have many ideas on how to improve that, and that's one of the main areas of focus over the next months, but today, we're proud to introduce our support for what we call a **multi-chain paywall**: a way for the paywall application to connect to several locks at once, on different chains!

The configuration for these is simple: just pass the network as part of the locks' custom values:

```
{
  locks: {
    "0xb77030a7e47a5eb942a4748000125e70be598632": {
      name: "Unlock Community",
      network: 137,
    }
  }
```

Additionally, we've added a feature to the paywall which lets developers configure which locks are shown when the user is making a purchase. For this, the `loadCheckoutModal` function now accepts an optional config (and defaults to the one used on the page). [Thanks a lot to [Paul](https://twitter.com/pswgnr) from the Unlock community [for his suggestion](https://github.com/unlock-protocol/unlock/issues/7072)!]


You can now embed locks from multiple chain in the same application! Also, you can customize the configuration for the checkout modal, independently of the paywall configuration!

You can now embed locks from multiple chain in the same application!

Multichain support in paywall

As transaction costs on Ethereum's mainnet keep sky-rocketing (it's a good thing!), like many other projects in the web3 space, we are exploring ways to provide a seamless experience in the Ethereum ecosystem, without the costs associated with a blockchain used heavily for large-value transactions. A few weeks ago, we launch the <a href="/blog/xdai">Unlock Protocol on xDAI</a> and we're working on several more.
Unfortunately, there is a cost to using multiple chains: complexity for users. We have many ideas on how to improve that, and that's one of the main areas of focus over the next months, but today, we're proud to introduce our support for what we call a multi-chain paywall: a way for the paywall application to connect to several locks at once, on different chains!
The configuration for these is simple: just pass the network as part of the locks' custom values:
<pre><code>{
 locks: {
 "0xb77030a7e47a5eb942a4748000125e70be598632": {
 name: "Unlock Community",
 network: 137,
 }
 }
</code></pre>
Additionally, we've added a feature to the paywall which lets developers configure which locks are shown when the user is making a purchase. For this, the <code>loadCheckoutModal</code> function now accepts an optional config (and defaults to the one used on the page). [Thanks a lot to <a href="https://twitter.com/pswgnr">Paul</a> from the Unlock community <a href="https://github.com/unlock-protocol/unlock/issues/7072">for his suggestion</a>!]


Guest written by artist Patrick Gerard from [r0se.art](https://r0se.art)

## New art project r0se launches with eco-friendly XDAI blockchain using Unlock

In the 1970’s, TV held out the promise of possibility for media artists as a new, networked, broadcasting technology that could allow them to bypass the limitations of gallery exhibition and geographical boundaries, and distribute their art to the many and not the few. The internet did the same. Except part of the problem was that these mediums eventually became centrally mediated and finding ways to finance the process was challenging. The blockchain is now emerging and it proposes a way for artists to solve this.

I make art using different mediums. Mostly drawing, video, poetry, books and multimedia art for the browser. About a year ago, I decided I wanted to bring it all together and put it on the web as an improvised collage. I wasn’t sure what the outcome of that would be really. Mostly I was interested to see what would happen when the different fictional and literary elements of my work started to impact upon and interact with one another.

A project like this would normally require funding. But I wanted to avoid that and try something that wasn’t supported by a gallery or funding body, to see if that would allow me a different kind of freedom to explore more experimental ways of working that weren’t bound by time or place.

I also didn’t have a way to personally fund it, so I started to look at new, open source and open web technologies like Ethereum, IPFS and Unlock-Protocol to see if I could understand and use them.

As things took shape, it became natural for me to think about how it should relate to an audience. Making art freely accessible can diminish its integrity. But the project was also never about selling the work only. So the question became, could I find an alternative way to allow people to engage with my work online that was more democratic and inclusive and that also protected its integrity?

Using a crypto token seemed like a way to do this. Except tokenizing usually takes place at the beginning of a project, as a way to crowdfund a proof of concept. By developing the work independently and taking it to a certain maturity myself, the token came instead to represent something more like a proof of work, or a proof of my artistic work. This, I think, is where its value now lies.

I was drawn to Unlock, not as a membership protocol necessarily, but because it offered a way to freely and very generously explore different ways of developing a token using a new, open web technology in which I saw potential to solve what is a difficult problem for artists. That is, how to distribute art openly and to as many people as possible, in a way that protects its integrity as artwork of value, and that is financially sustainable.

The result is the [r0se](https://r0se.art) platform, which is now live. It has become a safe place where I can make and add new work, change it freely, add my books or videos or poems or other writing, publish new ideas, try new things, and bring it all together as a broad, improvised composition. And I can make this available to others using Unlock tokens.

Unlock makes it possible to mint tokens on the more sustainable, energy efficient and ecologically-friendly blockchain XDAI. XDAI is a side-chain of the Ethereum network that uses proof-of-stake which incurs almost zero gas fees. For now, I’ve minted three tokens. They each represent different ways to come and see my work for a certain period of time. A one month, one year and unlimited token. This also opens up different ways to support the progress of the work and how it evolves over the long term.

Although it is early days, I feel that as more tools like Unlock become available to artists, it may give rise to something like a new avant garde, which will be characterized by a resistance to the spectacle of museum exhibition, and that will instead make use of the decentralized web as an undercurrent that flows beneath the mainstream. In this, it will be possible to distribute art in new and disruptive ways. With recent media hype about NFTs focusing on collectibility, high sales figures and on art as a medium of ownership, I think artists may miss the potential the NFT has for other, more democratic and inclusive ways to distribute their work. Unlock is providing a way to do this. They’re doing something alternative with NFTs that can also be ecologically sustainable. And that’s interesting to me.

[r0se.art](https://r0se.art)


Artist uses XDAI blockchain and Unlock Protocol to explore new, inclusive ways of distributing their art to a global audience.

New art project r0se launches with eco-friendly XDAI blockchain using Unlock.

r0se

Guest written by artist Patrick Gerard from <a href="https://r0se.art">r0se.art</a>
<h2>New art project r0se launches with eco-friendly XDAI blockchain using Unlock</h2>
In the 1970’s, TV held out the promise of possibility for media artists as a new, networked, broadcasting technology that could allow them to bypass the limitations of gallery exhibition and geographical boundaries, and distribute their art to the many and not the few. The internet did the same. Except part of the problem was that these mediums eventually became centrally mediated and finding ways to finance the process was challenging. The blockchain is now emerging and it proposes a way for artists to solve this.
I make art using different mediums. Mostly drawing, video, poetry, books and multimedia art for the browser. About a year ago, I decided I wanted to bring it all together and put it on the web as an improvised collage. I wasn’t sure what the outcome of that would be really. Mostly I was interested to see what would happen when the different fictional and literary elements of my work started to impact upon and interact with one another.
A project like this would normally require funding. But I wanted to avoid that and try something that wasn’t supported by a gallery or funding body, to see if that would allow me a different kind of freedom to explore more experimental ways of working that weren’t bound by time or place.
I also didn’t have a way to personally fund it, so I started to look at new, open source and open web technologies like Ethereum, IPFS and Unlock-Protocol to see if I could understand and use them.
As things took shape, it became natural for me to think about how it should relate to an audience. Making art freely accessible can diminish its integrity. But the project was also never about selling the work only. So the question became, could I find an alternative way to allow people to engage with my work online that was more democratic and inclusive and that also protected its integrity?
Using a crypto token seemed like a way to do this. Except tokenizing usually takes place at the beginning of a project, as a way to crowdfund a proof of concept. By developing the work independently and taking it to a certain maturity myself, the token came instead to represent something more like a proof of work, or a proof of my artistic work. This, I think, is where its value now lies.
I was drawn to Unlock, not as a membership protocol necessarily, but because it offered a way to freely and very generously explore different ways of developing a token using a new, open web technology in which I saw potential to solve what is a difficult problem for artists. That is, how to distribute art openly and to as many people as possible, in a way that protects its integrity as artwork of value, and that is financially sustainable.
The result is the <a href="https://r0se.art">r0se</a> platform, which is now live. It has become a safe place where I can make and add new work, change it freely, add my books or videos or poems or other writing, publish new ideas, try new things, and bring it all together as a broad, improvised composition. And I can make this available to others using Unlock tokens.
Unlock makes it possible to mint tokens on the more sustainable, energy efficient and ecologically-friendly blockchain XDAI. XDAI is a side-chain of the Ethereum network that uses proof-of-stake which incurs almost zero gas fees. For now, I’ve minted three tokens. They each represent different ways to come and see my work for a certain period of time. A one month, one year and unlimited token. This also opens up different ways to support the progress of the work and how it evolves over the long term.
Although it is early days, I feel that as more tools like Unlock become available to artists, it may give rise to something like a new avant garde, which will be characterized by a resistance to the spectacle of museum exhibition, and that will instead make use of the decentralized web as an undercurrent that flows beneath the mainstream. In this, it will be possible to distribute art in new and disruptive ways. With recent media hype about NFTs focusing on collectibility, high sales figures and on art as a medium of ownership, I think artists may miss the potential the NFT has for other, more democratic and inclusive ways to distribute their work. Unlock is providing a way to do this. They’re doing something alternative with NFTs that can also be ecologically sustainable. And that’s interesting to me.
<a href="https://r0se.art">r0se.art</a>

> Guest written by Community builder Patrick Gallagher

Discord and Telegram are the best places for tech-savvy teams or communities to chat. And with any new communication platform, we need a way to isolate the signal from the noise.

To solve this, we built Swordy Bot. The bot is integrated with Unlock Protocol, so you can limit access to only community members who hold a specific Lock token (NFT). Best of all, its completely automated!

![A few discord channels with locks](/images/blog/swordy-bot-intro/channels.png)

If the user doesn't have the necessary Lock token in their wallet, they are directed to the Unlock Protocol app, where they can purchase one.

Big thank you to the Unlock Protocol for sponsoring this bounty. Working with the team has been a breeze, and its really cool that they support people who want to build with their protocol. If you're a developer, I definitely would recommend looking at their other bounties.

## How it works

It uses complicate machine learning... just kidding! It's actually pretty simple. The bot checks the user's wallet for the appropriate key to the Lock. If they have it, then the user earns the appropriate roles.

The basic steps for setting up the bot are:

Step 1. Add the bot to your server at [swordybot.com](https://swordybot.com)

Step 2. Add the requirements for a role using `!add-lock`

<img src="/images/blog/swordy-bot-intro/add-lock.png" alt="A admin invoking the !add-lock command" height="100px"/>

Step 3. Users can get access using the `!unlock` command

<img src="/images/blog/swordy-bot-intro/invoke.png" alt="A user invoking the !unlock command" height="100px"/>

If successful you'll see a message like this, giving you some new roles:

<img src="/images/blog/swordy-bot-intro/knighted.png" alt="A message from the bot that the user has been assigned roles" height="200px"/>

## How I built it

Integrating with Unlock Protocol was extremely simple. The magic all happens in this one line of code where I call the `getHasValidKey` function on the appropriate contract.

```js
const hasValidKey = await lockContract.getHasValidKey(userAddress)
```

If you're interested in building your own bot, or building with Unlock, most of the code for Swordy Bot is available [here](https://github.com/pi0neerpat/unlock-protocol-bot/blob/e448d1f81a49c4b0b021d09bb623991ae87c55f5/api/src/lib/unlockProtocol/unlockProtocol.js#L26).

## What's next

We are super excited to continue building. Let us know what you want to see and give us feedback in our [Discord](https://discord.gg/Nw3y4GtBSh)

If you like where we are headed, consider <a href="https://twitter.com/swordybot?ref_src=twsrc%5Etfw" class="twitter-follow-button" data-show-count="false">follow @swordybot</a>

Thanks to the Unlock developer community, you can now use Unlock in Discord.

Manage your community auto-magically!

Introducing Swordy Bot

<blockquote>
Guest written by Community builder Patrick Gallagher
</blockquote>
Discord and Telegram are the best places for tech-savvy teams or communities to chat. And with any new communication platform, we need a way to isolate the signal from the noise.
To solve this, we built Swordy Bot. The bot is integrated with Unlock Protocol, so you can limit access to only community members who hold a specific Lock token (NFT). Best of all, its completely automated!
<img src="/images/blog/swordy-bot-intro/channels.png" alt="A few discord channels with locks">
If the user doesn't have the necessary Lock token in their wallet, they are directed to the Unlock Protocol app, where they can purchase one.
Big thank you to the Unlock Protocol for sponsoring this bounty. Working with the team has been a breeze, and its really cool that they support people who want to build with their protocol. If you're a developer, I definitely would recommend looking at their other bounties.
<h2>How it works</h2>
It uses complicate machine learning... just kidding! It's actually pretty simple. The bot checks the user's wallet for the appropriate key to the Lock. If they have it, then the user earns the appropriate roles.
The basic steps for setting up the bot are:
Step 1. Add the bot to your server at <a href="https://swordybot.com">swordybot.com</a>
Step 2. Add the requirements for a role using <code>!add-lock</code>
<img src="/images/blog/swordy-bot-intro/add-lock.png" alt="A admin invoking the !add-lock command" height="100px"/>
Step 3. Users can get access using the <code>!unlock</code> command
<img src="/images/blog/swordy-bot-intro/invoke.png" alt="A user invoking the !unlock command" height="100px"/>
If successful you'll see a message like this, giving you some new roles:
<img src="/images/blog/swordy-bot-intro/knighted.png" alt="A message from the bot that the user has been assigned roles" height="200px"/>
<h2>How I built it</h2>
Integrating with Unlock Protocol was extremely simple. The magic all happens in this one line of code where I call the <code>getHasValidKey</code> function on the appropriate contract.
<pre><code class="language-js">const hasValidKey = await lockContract.getHasValidKey(userAddress)
</code></pre>
If you're interested in building your own bot, or building with Unlock, most of the code for Swordy Bot is available <a href="https://github.com/pi0neerpat/unlock-protocol-bot/blob/e448d1f81a49c4b0b021d09bb623991ae87c55f5/api/src/lib/unlockProtocol/unlockProtocol.js#L26">here</a>.
<h2>What's next</h2>
We are super excited to continue building. Let us know what you want to see and give us feedback in our <a href="https://discord.gg/Nw3y4GtBSh">Discord</a>
If you like where we are headed, consider <a href="https://twitter.com/swordybot?ref_src=twsrc%5Etfw" class="twitter-follow-button" data-show-count="false">follow @swordybot</a>


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

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

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

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


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

Let a thousand wallets bloom!

Support for WalletConnect

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


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

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

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

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

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

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

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


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

Unlock is now available on xDAI!

XDAI

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


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

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

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

# How does UDT work?

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

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

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

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

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

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

# How can I earn UDT?

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

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

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

# What is next?

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

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

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


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

Starting the decentralization of Unlock!

Launching Unlock Discount Tokens

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


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

# Introducing the Key Purchaser contract

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

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

# How does it work?

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

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

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

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

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

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

# A full example

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

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

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

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

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

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

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

## Next steps

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

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


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

The Unlock Protocol supports recurring memberships!

Recurring Memberships

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


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

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

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

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

# Key Purchase Hook

The Key purchase hook actually has 2 entry points:

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

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

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

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

# Key Cancel Hook

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

# Examples

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

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


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

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

Hooks

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


# 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>
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.
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 <a href="https://etherscan.io/address/0xCE62D71c768aeD7EA034c72a1bc4CF58830D9894#code">the ABI of the lock on this blog</a>.
<h1>npm modules</h1>
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>!
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>
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!


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

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.
<h1>Not All Dapp Browsers Behave The Same</h1>
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.
<h1>It's Not Enough to Have Just Any Provider</h1>
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.
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!