diff --git a/docs/docs/core-protocol/public-lock/README.md b/docs/docs/core-protocol/public-lock/README.md index 879a14b5f5e..68d5922a4ff 100644 --- a/docs/docs/core-protocol/public-lock/README.md +++ b/docs/docs/core-protocol/public-lock/README.md @@ -17,7 +17,7 @@ Each lock is a standalone contract with its own deployment, address, and storage - A given user may own only 1 key (NFT) at a time as a default, but that can be changed using the `setMaxKeysPerAddress` function. Additionally, the Lock smart contract has multiple capabilities: -- _Administrative_: these are the functions that change rights (see[ access control](./access-control/)) associated to the lock or individual parameters for the lock a such as its name or of course its price. Finally, there is a method to withdraw funds from the lock contract itself. +- _Administrative_: these are the functions that change rights (see[ access control](./access-control/)) associated to the lock or individual parameters for the lock such as its name or of course its price. Finally, there is a method to withdraw funds from the lock contract itself. - _Transferring key ownership_: keys can be purchased from the lock smart contract itself or from another user who purchased one previously. Another element is that keys can be purchased on behalf of somebody else \(this is important because this lets somebody pay gas fees on behalf of somebody else\) - _Changing key attributes_: the keys have an expiration date which can be changed \(for an earlier date by the lock owner\) as well as data attributes which can be changed to something else. @@ -63,7 +63,7 @@ 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) +- New Solidity version 0.8.21 (creating issues on some chains that won't support new `PUSH0` evm opcode) - Fix potential overflow when merging keys ### Version 13 @@ -100,7 +100,7 @@ The configuration for a key’s default duration and available quantity (both pe #### `expirationTimestamp` -This adds the expiration timestamp on ExpirationDuration event emitted by the time machine when time gets added or substracted to/from a key. +This adds the expiration timestamp on ExpirationDuration event emitted by the time machine when time gets added or subtracted to/from a key. #### Events and schema changes diff --git a/docs/docs/core-protocol/public-lock/hooks.md b/docs/docs/core-protocol/public-lock/hooks.md index cd168d37f2c..9e51d8e044d 100644 --- a/docs/docs/core-protocol/public-lock/hooks.md +++ b/docs/docs/core-protocol/public-lock/hooks.md @@ -17,7 +17,7 @@ We currently support 7 hooks (as of v12). If your lock uses a previous version, - onKeyCancelHook: called when a key is canceled - onTokenUriHook: called when the tokenURI is fetched - onValidKeyHook: called when checking if a user has a valid key -- onKeyTransferHook: called when a key is transfered from an address to another. +- onKeyTransferHook: called when a key is transferred from an address to another. ## onGrantKey Hook @@ -50,7 +50,7 @@ interface ILockKeyGrantHook ## onKeyExtend Hook -The `onKeyExtendHook` allows you create custom logic when a key is extended or renewed. This could enable use cases where for instance key metadata is updated, maybe you want to update the image when renewals happen. It could enable rewards programs where you increment a reward point total everytime a membership is renewed. +The `onKeyExtendHook` allows you create custom logic when a key is extended or renewed. This could enable use cases where for instance key metadata is updated, maybe you want to update the image when renewals happen. It could enable rewards programs where you increment a reward point total every time a membership is renewed. A KeyExtendHook should implement the following interface. @@ -82,7 +82,7 @@ It contains 2 main functions: 1. `keyPurchasePrice` which is used to determine the purchase price before issuing a transaction, 2. `onKeyPurchase` which is called every time a key is sold. -If either of these fail, then the whole purchase will revert. +If either of these fails, then the whole purchase will revert. The `ILockKeyPurchaseHook` contract interface describes the parameters of each function (from, recipient, original price, price paid, etc), so the hook can be properly implemented. @@ -136,7 +136,7 @@ interface ILockValidKeyHook address lockAddress, // the address of the current lock address keyOwner, // the potential owner of a key uint256 expirationTimestamp, // the key expiration timestamp - bool isValidKey // the validity in the lock contrat + bool isValidKey // the validity in the lock contract ) external view returns (bool); diff --git a/docs/docs/core-protocol/smart-contracts-api/Unlock.md b/docs/docs/core-protocol/smart-contracts-api/Unlock.md index 1eb3dda3ba5..f472b72e23d 100644 --- a/docs/docs/core-protocol/smart-contracts-api/Unlock.md +++ b/docs/docs/core-protocol/smart-contracts-api/Unlock.md @@ -24,7 +24,7 @@ function addLockTemplate(address impl, uint16 version) external nonpayable Add a PublicLock template to be used for future calls to `createLock`. -_This is used to upgrade conytract per version number_ +_This is used to upgrade contract per version number_ #### Parameters @@ -105,8 +105,8 @@ _internally call `createUpgradeableLock`_ | \_expirationDuration | uint256 | the duration of the lock (pass 0 for unlimited duration) | | \_tokenAddress | address | set to the ERC20 token address, or 0 for ETH. | | \_keyPrice | uint256 | the price of each key | -| \_maxNumberOfKeys | uint256 | the maximum nimbers of keys to be edited | -| \_lockName | string | the name of the lock param \_salt [deprec] -- kept only for backwards copatibility This may be implemented as a sequence ID or with RNG. It's used with `create2` to know the lock's address before the transaction is mined. | +| \_maxNumberOfKeys | uint256 | the maximum numbers of keys to be edited | +| \_lockName | string | the name of the lock param \_salt [deprec] -- kept only for backwards compatibility This may be implemented as a sequence ID or with RNG. It's used with `create2` to know the lock's address before the transaction is mined. | | \_5 | bytes12 | undefined | #### Returns @@ -176,7 +176,7 @@ function estimatedGasForPurchase() external view returns (uint256) function getAdmin() external view returns (address) ``` -Returns the ProxyAdmin contract address that manage upgrades for the current Unlock contract. +Returns the ProxyAdmin contract address that manages upgrades for the current Unlock contract. _this reads the address directly from storage, at the slot `_ADMIN_SLOT` defined by Open Zeppelin's EIP1967 Proxy implementation which corresponds to the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1_ @@ -340,7 +340,7 @@ _Returns the address of the current owner._ function postLockUpgrade() external nonpayable ``` -Call executed by a lock after its version upgrade triggred by `upgradeLock` - PublicLock v12 > v13 (mainnet): migrate an existing Lock to another instance of the Unlock contract +Call executed by a lock after its version upgrade triggered by `upgradeLock` - PublicLock v12 > v13 (mainnet): migrate an existing Lock to another instance of the Unlock contract _The `msg.sender` will be the upgraded lock_ @@ -410,7 +410,7 @@ Match lock templates addresses with version numbers function publicLockLatestVersion() external view returns (uint16 _version) ``` -Retrive the latest existing lock template version +Retrieve the latest existing lock template version #### Returns @@ -461,7 +461,7 @@ _[DEPRECATED] Kept for backwards compatibility This function will keep track of function recordKeyPurchase(uint256 _value, address _referrer) external nonpayable ``` -This function keeps track of the added GDP, as well as grants of discount tokens to the referrer, if applicable. The number of discount tokens granted is based on the value of the referal, the current growth rate and the lock's discount token distribution rate This function is invoked by a previously deployed lock only. +This function keeps track of the added GDP, as well as grants of discount tokens to the referrer, if applicable. The number of discount tokens granted is based on the value of the referral, the current growth rate and the lock's discount token distribution rate This function is invoked by a previously deployed lock only. #### Parameters @@ -574,7 +574,7 @@ Set the UDT Swap and Burn contract address function swapAndBurn(address token, uint256 amount, uint24 poolFee) external nonpayable ``` -Send tokens held by this contract to the UDT SwapBurner contract. The tokens sent to the contract are then swapped for UDT and UDT itself will be sent to a burner address.This function can be called by anyone (not only the contract owner) as a way to ensure decentralization. +Send tokens held by this contract to the UDT SwapBurner contract. The tokens sent to the contract are then swapped for UDT and UDT itself will be sent to a burner address. This function can be called by anyone (not only the contract owner) as a way to ensure decentralization. #### Parameters @@ -630,7 +630,7 @@ _Transfers ownership of the contract to a new account (`newOwner`). Can only be function transferTokens(address token, address to, uint256 amount) external nonpayable ``` -Functions which transfers tokens held by the contract It handles both ERC20 and the base currency. +Function which transfers tokens held by the contract It handles both ERC20 and the base currency. _This function is onlyOwner_ diff --git a/docs/docs/governance/grants-bounties/udt-grantee-handbook.md b/docs/docs/governance/grants-bounties/udt-grantee-handbook.md index a959581390e..34c7e1f3ec9 100644 --- a/docs/docs/governance/grants-bounties/udt-grantee-handbook.md +++ b/docs/docs/governance/grants-bounties/udt-grantee-handbook.md @@ -104,7 +104,7 @@ identify important dates. The final milestone should include success metrics or ROI. Here are some examples based on your application type. -- For a membership implementation: the number of members joined your through +- For a membership implementation: the number of members who joined you through your platform. - For an event: the number of tickets sold. - For use with credentials: the number of credentials handed out. diff --git a/docs/docs/governance/unlock-dao/cross-chain-governance.mdx b/docs/docs/governance/unlock-dao/cross-chain-governance.mdx index 465db4ec309..e0ce42f1edc 100644 --- a/docs/docs/governance/unlock-dao/cross-chain-governance.mdx +++ b/docs/docs/governance/unlock-dao/cross-chain-governance.mdx @@ -2,7 +2,7 @@ sidebar_position: 2 title: Cross-Chain Governance description: >- - Workflow to propagate DAO proposals accross multiple chains + Workflow to propagate DAO proposals across multiple chains --- import { networks } from '@unlock-protocol/networks' @@ -11,7 +11,7 @@ To fully decentralize the maintenance and management of the protocol contracts, ## How it works -To reach other chains, calls emitted from the mainnet DAO go though the [Connext bridge](https://www.connext.network/) and are executed on the other side of the bridge, after a period of cooldown. +To reach other chains, calls emitted from the mainnet DAO go through the [Connext bridge](https://www.connext.network/) and are executed on the other side of the bridge, after a period of cooldown. ``` (mainnet) (destination chain) (cooldown period) diff --git a/governance/README.md b/governance/README.md index b3e722489ac..37ad3dfc33c 100644 --- a/governance/README.md +++ b/governance/README.md @@ -1,6 +1,6 @@ # Unlock Protocol Governance -This folders contains all the tools to manage the Unlock Protocol (contracts, DAO, etc). +This folder contains all the tools to manage the Unlock Protocol (contracts, DAO, etc). To get the list of all available tasks use `yarn hardhat --help`. @@ -138,7 +138,7 @@ yarn hardhat deploy:template --network tenderly ### Make a DAO proposal -1. First, create a file in the `proposals` folder that describe the proposal itself. The file should contain either a js async function or a literal object and should export as default an object containing: 1. the title of the proposal and 2. an array with the description of the calls to send - in following format: +1. First, create a file in the `proposals` folder that describes the proposal itself. The file should contain either a js async function or a literal object and should export as default an object containing: 1. the title of the proposal and 2. an array with the description of the calls to send - in following format: #### Exports a literal object @@ -207,7 +207,7 @@ RUN_FORK=8453 yarn hardhat gov --gov-address 0x65bA0624403Fc5Ca2b20479e9F626eD4D --proposal proposals/up/.js ``` -Additionnaly, you can pass arguments to your proposal script via CLI positional args. +Additionally, you can pass arguments to your proposal script via CLI positional args. 3. When things are ready, post it to the DAO! @@ -237,7 +237,7 @@ yarn run scripts/uniswap/addLiquidity.js ## Cross-Chain DAO Proposals -To maintain the integrity of the protocol accross various chains, we use a pattern of DAO proposals that allows execution on multiple chains. Messaging is sent accross the [Connext bridge](https://connext.network) to all supported chains. +To maintain the integrity of the protocol across various chains, we use a pattern of DAO proposals that allows execution on multiple chains. Messaging is sent across the [Connext bridge](https://connext.network) to all supported chains. ### Prepare a cross-chain proposal @@ -266,7 +266,7 @@ Once the proposal has been through the timelock embargo period and has been exec To execute these commands, you will need the hash from the transaction that executed the proposal on the DAO. The transaction contains the IDs of the bridge calls that will be used by the scripts to fetch information. -NB: On [Tally.xyz](://www.tally.xyz/gov/unlock), a etherscan link containing the hash can be found on the upper left button next to _Proposal Executed_. +NB: On [Tally.xyz](://www.tally.xyz/gov/unlock), an etherscan link containing the hash can be found on the upper left button next to _Proposal Executed_. ``` export PROPOSAL_EXECUTION_TX=<0x....> @@ -315,7 +315,7 @@ NB: The tmp file with all txs statuses is required, so you need to first run the ### Add a new network to the cross-chain governance -As the Connext bridge supports more networks, they need to added to the cross chain gov process (see [supported networks](https://docs.connext.network/resources/deployments) on Connext docs). +As the Connext bridge supports more networks, they need to be added to the cross chain gov process (see [supported networks](https://docs.connext.network/resources/deployments) on Connext docs). The process is as follow: diff --git a/locksmith/README.md b/locksmith/README.md index 8867b89d917..fbf298b52a5 100644 --- a/locksmith/README.md +++ b/locksmith/README.md @@ -48,7 +48,7 @@ Once the database has been configured (per above), make sure to migrate by calli ## Running Locksmith -For running in production, use `yarn start` otherwise `yarn dev` which will restart the server on file changes. This requires using 1password locally and have access to the Unlock Labs vault. +For running in production, use `yarn start` otherwise `yarn dev` which will restart the server on file changes. This requires using 1password locally and having access to the Unlock Labs vault. You can start a worker with `yarn worker:start`. diff --git a/packages/README.md b/packages/README.md index 6b135595dbe..bc5208bc26f 100644 --- a/packages/README.md +++ b/packages/README.md @@ -20,7 +20,7 @@ We rely on [yarn release workflow](https://yarnpkg.com/features/release-workflow ### Versions -Yarn use "deffered" version release, which means that we first prepare a file that state which packages should be updated - and how (minor, major, etc). Then the new version number is applied to the package and updated in deps accross the entire repo. +Yarn use "deferred" version release, which means that we first prepare a file that state which packages should be updated - and how (minor, major, etc). Then the new version number is applied to the package and updated in deps across the entire repo. Shortcuts commands available from the root repo: diff --git a/subgraph/README.md b/subgraph/README.md index 74fed8349b3..227de960204 100644 --- a/subgraph/README.md +++ b/subgraph/README.md @@ -24,7 +24,7 @@ The `networks.json` file and `/config` files are generated from our `@unlock-pro yarn prepare:networks ``` -#### Contrat ABIs +#### Contract ABIs Unlock's contracts are upgradable, we parse the multiple ABIs that are required from our `@unlock-protocol/contracts` package. diff --git a/tests/README.md b/tests/README.md index 0c339d57866..44e79cac79f 100644 --- a/tests/README.md +++ b/tests/README.md @@ -18,7 +18,7 @@ First start a fully provisioned ETH node (with the Unlock contracts deployed and yarn start:infra ``` -then you nneed to export the subgraph URL, rebuild the networks package and run the test +then you need to export the subgraph URL, rebuild the networks package and run the test ```shell export SUBGRAPH_URL=http://localhost:8000/subgraphs/name/testgraph