Production Deploy (#13595)

* Manual deploy as of commit:5754dc53904ad66eca1df5508b523a4d23a39e13

* feat(unlock-app): responsive event landing page (#13596)

responsive event landing page

* upgraded uniswap deps (#13598)

.clabot

@@ -62,7 +62,10 @@
     "0xTxbi",
     "FedericoCaruso",
     "njokuScript",
-    "Calla-Ji"
+    "Calla-Ji",
+    "blahkheart",
+    "TylerSehr",
+    "ClockRide"
   ],
   "message": "Thank you for your pull request and welcome to Unlock! We require contributors to sign our [Contributor License Agreement](https://github.com/unlock-protocol/unlock/blob/master/CLA.txt), and we don't seem to have the users {{usersWithoutCLA}} on file. \nIn order for us to review and merge your code, please open _another_ pull request with a single modification: your github username added to the file `.clabot`.\nThank you! "
 }

.github/actions/blog/action.yml

@@ -11,7 +11,7 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
 
       - name: Set up Python
         uses: actions/setup-python@v4

.github/workflows/_heroku.yml

@@ -49,7 +49,7 @@ jobs:
         shell: bash
         id: check_changes
       - name: Load secrets from 1Password
-        uses: 1Password/load-secrets-action@v1.3.2
+        uses: 1Password/load-secrets-action@v2.0.0
         with:
           export-env: true
         env:

.github/workflows/daily-check.yml

@@ -12,7 +12,7 @@ jobs:
         with:
           fetch-depth: 0
       - name: Load secrets from 1Password
-        uses: 1Password/load-secrets-action@v1.3.2
+        uses: 1Password/load-secrets-action@v2.0.0
         with:
           export-env: true
         env:

.github/workflows/master.yml

@@ -73,7 +73,7 @@ jobs:
         with:
           fetch-depth: 0
       - name: Load secrets from 1Password
-        uses: 1Password/load-secrets-action@v1.3.2
+        uses: 1Password/load-secrets-action@v2.0.0
         with:
           export-env: true
         env:

.github/workflows/production.yml

@@ -59,7 +59,7 @@ jobs:
         with:
           fetch-depth: 0
       - name: Load secrets from 1Password
-        uses: 1Password/load-secrets-action@v1.3.2
+        uses: 1Password/load-secrets-action@v2.0.0
         with:
           export-env: true
         env:

.github/workflows/pull-request.yml

@@ -76,7 +76,7 @@ jobs:
         with:
           fetch-depth: 0
       - name: Load secrets from 1Password
-        uses: 1Password/load-secrets-action@v1.3.2
+        uses: 1Password/load-secrets-action@v2.0.0
         with:
           export-env: true
         env:

docker/development/eth-node/package.json

@@ -10,13 +10,13 @@
   },
   "dependencies": {
     "@nomiclabs/hardhat-ethers": "2.2.3",
-    "@unlock-protocol/hardhat-plugin": "latest",
     "@unlock-protocol/contracts": "latest",
+    "@unlock-protocol/hardhat-plugin": "latest",
     "eslint": "8.54.0",
     "ethers": "5.7.2",
     "hardhat": "2.20.1",
     "hardhat-erc1820": "0.1.0",
     "ts-node": "10.9.2",
-    "typescript": "5.3.3"
+    "typescript": "5.4.3"
   }
 }

docs/docs/core-protocol/public-lock/README.md

@@ -47,11 +47,30 @@ Lock managers can also alter the behavior of their locks thru the use of [hooks]
 
 Changelogs can be found here for the last two versions.
 
+### Version 14
+
+**Released:**: Jan 2024
+
+The version 14 introduces several changes in user-facing features :
+
+- Introduces `setKeyExpiration` to allow a lock manager to update the timestamp of any existing keys freely
+- Modifies `getHasValidKey` so a hook has a final say while determining the validity of a key
+- Allows a lock manager to always transfer keys, even when transfers are disabled
+- Disables fees for lock managers when transferring or sharing a key
+
+For advanced users and developers, the lower level changes below are noteworthy:
+
+- Replace `UnlockUtils` dependencies by optimized Open Zeppelin implementation
+- Remove dev reward/cut when purchasing a key
+- Add unchecked scopes on math operations (gas optimisation)
+- New Solidity version 0.8.21 (creating issues on some chains that wont support new `PUSH0` evm opcode)
+- Fix potential overflow when merging keys
+
 ### Version 13
 
 **Released**: April 2023
 
-This new version improved gas consumption of most functions (by using Solidity custom errors instead of require statements). It solves issues that were appearing when canceling or burning membership keys. 
+This new version improved gas consumption of most functions (by using Solidity custom errors instead of require statements). It solves issues that were appearing when canceling or burning membership keys.
 
 The helpers functions `addKeyGranter` and `isKeyGranter` have been removed to reduce the size of the contract. The features are still accessible by calling directly `grantRole` and `hasRole` with `keccak256('KEY_GRANTER_ROLE')` as role.
 

docs/docs/core-protocol/unlock/README.md

@@ -11,3 +11,19 @@ This is our "factory" contract **(Unlock.sol)** and has several roles.
 As of summer 2021, the unlock contract is **owned** by a multi-sig wallet managed by Unlock Inc. Our goal is to move toward decentralization by transferring ownership of the Unlock contact to [the Unlock DAO](../../governance/unlock-dao/).
 
 This contract is upgradable using OpenZeppelin's upgradability framework. As of now, the ProxyAdmin is **owned** by a multi-sig wallet managed by Unlock Inc. Our goal is to move toward decentralization by transferring ownership of the Unlock contact to the [Unlock DAO](../../governance/unlock-dao/). Each implementation is versioned. The method `unlockVersion()` will yield the current version.
+
+# Changelog
+
+## Version 13
+
+**Released**: Feb 2024
+
+The main novelty in the version 13 of Unlock is a “swap and burn” feature that allow fees collected by the protocol to directly decrease the supply of UDT in circulation.
+
+### **How it works**
+
+- Fees are collected by the Unlock contract when a membership or subscription key is purchased or extended
+- Fees are kept by the main Unlock contract, and can be denominated in any native or ERC20 currencies
+- By calling the `swapAndBurn` function, the collected fees are sent from the Unlock contract to a contract that will 1) convert the tokens for the collected protocol fees to UDT (using Uniswap) and 2) send those UDT tokens to a burn address
+
+In earlier versions of the protocol, UDT governance tokens were distributed by the Unlock contract using a developer reward. This is now deprecated and should be replaced by the protocol fee. The protocol fee is not enabled by default, and it will be up to the DAO to enable it now that the tools are in place.

docs/docs/tools/checkout/README.md

@@ -7,19 +7,14 @@ description: >-
 
 # Checkout
 
-Unlock Protocol has an app, most people are familiar with the Dashboard, Members
-and Keychain portions, but that app has an endpoint called checkout which accepts
-a configuration object as params and returns a custom configured checkout experience.
+The Unlock Labs team built an application, on top of the Open Protocol: most people are familiar with the Dashboard, Members and Keychain portions, but that app has an endpoint called **Checkout** which accepts a configuration object as params and yields a custom configured checkout experience.
 
-## The experience
-
-This experience can also be used in a few different ways:
+The checkout can be used in a few different ways:
 
 1. Stand-alone as a link you distribute to your members via email, Discord, etc.
-   for minting your membership/ticket/credential NFT
-1. Embedded in your website directly
-1. In combination with the Paywall our javascript library which is a thin
-   wrapper around the checkout and Unlock APIs
+   for minting your membership/ticket/credential NFT,
+1. Embedded in your website directly,
+1. In combination with the [Paywall javascript library](../paywall.md).
 
 ## Examples
 
@@ -50,10 +45,9 @@ like by choosing "Create Checkout URL" from the menu options instead.
 ![unlock dashboard create checkout menu item](/img/tools/checkout/unlock-dashboard-create-checkout-menu.png)
 
 This will take you to the "Checkout Builder" where you can build your checkout and
-see what your changes look like in realtime. 
-
+see what your changes look like in realtime.
 
 If you'd like to use that configuration
-with your [Paywall](../paywall), download the configuration file by clicking on the "Download JSON" button. 
+with your [Paywall](../paywall), download the configuration file by clicking on the "Download JSON" button.
 
 ![unlock dashboard checkout builder](/img/tools/checkout/dashboard-checkout-builder.png)

docs/docs/tools/checkout/configuration.md

@@ -10,18 +10,26 @@ sidebar_position: 1
 
 ## Building your URL
 
-All of the purchase URLs start with the following base
+First, you can always use the [Checkout Buidler](https://app.unlock-protocol.com/locks/checkout-url) which provides a no-code tool to configure a checkout. At the end of it, you can copy the URL and use however you want.
+
+You can also programmatically build your own checkout URLs. All of the purchase URLs start with the following base:
 
 ```
 https://app.unlock-protocol.com/checkout?
 ```
 
-After this, you will need to include the following parameters:
+After this, you will need to include the following **required** parameters:
 
 - `paywallConfig=...` where `...` is replaced with the URL-encoded version of a JSON `paywallConfig` object. The next section will show you how to build this object.
 - `redirectUri=...` where `...` is replaced with the URL-encodded address of a webpage where the user will be redirected when their membership is valid.
 
 These parameters are all separated by the `&` sign and you can use online tools such as [https://www.urlencoder.io/](https://www.urlencoder.io/) to build the encoded version of the parameters.
+Note: if you used the builder to create the Checkout URL, you can replace the `paywallConfig` with its `id`.
+
+Optionally, you can add the following parameters:
+
+- `referrerAddress`: you can pass a wallet address that will be used as `referrer` for each transaction performed from that address. Please check [our docs about referrals](../../core-protocol/public-lock/referrals.md).
+- `promo`: if your membership contract uses the Promo Hook, you can pass the `promo` code so that it is pre-filled in the checkout UI.
 
 ### Example
 
@@ -39,7 +47,7 @@ The `paywallConfig` is a JSON object which includes a set of customizations for
 - `title`: _optional string_, a title for your checkout. This will show up on the head.
 - `icon`: _optional string_, the URL for a icon to display in the top left corner of the modal.
 - `persistentCheckout`: _optional boolean_: `true` if the modal cannot be closed, defaults to `false` when embedded. When closed, the user will be redirected to the `redirect` query param when using a purchase address (see above).
-- `referrer`: _optional string_. The address which will [receive UDT tokens](../../governance/unlock-dao-tokens) (if the transaction is applicable)
+- `referrer`: _optional string_. The address which will [receive UDT tokens](../../governance/unlock-dao-tokens) (if the transaction is applicable). It can also be passed as a query string `referrerAddress`.
 - `messageToSign`: _optional string_. If supplied, the user is prompted to sign this message using their wallet. If using a checkout URL, a `signature` query param is then appended to the `redirectUri` (see above). If using the embedded paywall, the `unlockProtocol.authenticated` includes the `signature` attribute.
 - `pessimistic`: _optional boolean_ defaults to `false`. By default, to reduce friction, we do not require users to wait for the transaction to be mined before offering them to be redirected. By setting this to `true`, users will need to wait for the transaction to have been mined in order to proceed to the next step.
 - `hideSoldOut`: _optional boolean_ defaults to `false`. When set to true, sold our locks are not shown to users when they load the checkout modal.