Request form
Lens Protocol
  • Social
  • Protocol
Docs
Source
ChefGPT

Lens Protocol is a composable and decentralized social graph, ready for you to build on so you can focus on creating a great experience, not scaling your users.

ERC721Enumerable :
This implements an optional extension of {ERC721} defined in the EIP that adds enumerability of all the token ids in the contract as well as all token ids owned by each account. NOTE: Modified from Openzeppelin to inherit from a modified ERC721 contract.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
ERC721Time :
Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}. Modifications: 1. Refactored _operatorApprovals setter into an internal function to allow meta-transactions. 2. Constructor replaced with an initializer. 3. Mint timestamp is now stored in a TokenData struct alongside the owner address.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
InteractionLogic :
The functions are external, so they are called from the hub via `delegateCall` under the hood.
PublishingLogic :
The functions are external, so they are called from the hub via `delegateCall` under the hood. Furthermore, expected events are emitted from this library instead of from the hub to alleviate code size concerns.
createComment(DataTypes.CommentData,uint256,mapping(uint256 => DataTypes.ProfileStruct) storage,mapping(uint256 => mapping(uint256 => DataTypes.PublicationStruct)) storage,mapping(address => bool) storage,mapping(address => bool) storage) :
This function is unique in that it requires many variables, so, unlike the other publishing functions, we need to pass the full CommentData struct in memory to avoid a stack too deep error.
createPost(uint256,string,address,bytes,address,bytes,uint256,mapping(uint256 => mapping(uint256 => DataTypes.PublicationStruct)) storage,mapping(address => bool) storage,mapping(address => bool) storage) :
To avoid a stack too deep error, reference parameters are passed in memory rather than calldata.
LensPeriphery :
This is useful because it allows clients to filter out follow NFTs that were transferred to a recipient by another user (i.e. Not a mint) and not register them as "following" unless the recipient explicitly toggles the follow here.
UIDataProvider :
This is a helper contract to fetch a profile and its latest publication in a single call.
Helper :
This is a helper contract used for internal testing. NOTE: This contract is not meant to be deployed and is unsafe for use.
batchDelegate(address,address,address) :
This is a helper function to aid in testing same-block delegation in the FollowNFT contract.
getBlockNumber() :
This is a helper function that exposes the block number due to the inconsistency of fetching the block number from scripts.
MockLensHubV2 :
A mock upgraded LensHub contract that is used mainly to validate that the initializer works as expected and that the storage layout after an upgrade is valid.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
MockLensHubV2BadRevision :
A mock upgraded LensHub contract that is used to validate that the initializer cannot be called with the same revision.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
TransparentUpgradeableProxy :
This contract implements a proxy that is upgradeable by an admin. To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector clashing], which can potentially be used in an attack, this contract uses the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two things that go hand in hand: 1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if that call matches one of the admin functions exposed by the proxy itself. 2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation. If the admin tries to call a function on the implementation it will fail with an error that says "admin cannot fallback to proxy target". These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due to sudden errors when trying to call a function from the proxy implementation. Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way, you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy.
admin() :
Returns the current admin. NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyAdmin}. TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`
changeAdmin(address) :
Changes the admin of the proxy. Emits an {AdminChanged} event. NOTE: Only the admin can call this function. See {ProxyAdmin-changeProxyAdmin}.
constructor :
Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and optionally initialized with `_data` as explained in {ERC1967Proxy-constructor}.
implementation() :
Returns the current implementation. NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyImplementation}. TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
upgradeTo(address) :
Upgrade the implementation of the proxy. NOTE: Only the admin can call this function. See {ProxyAdmin-upgrade}.
upgradeToAndCall(address,bytes) :
Upgrade the implementation of the proxy, and then call a function from the new implementation as specified by `data`, which should be an encoded function call. This is useful to initialize new storage variables in the proxied contract. NOTE: Only the admin can call this function. See {ProxyAdmin-upgradeAndCall}.
VersionedInitializable :
Helper contract to implement initializer functions. To use it, replace the constructor with a function that has the `initializer` modifier. WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors. This is slightly modified from [Aave's version.](https://github.com/aave/protocol-v2/blob/6a503eb0a897124d8b9d126c915ffdf3e88343a9/contracts/protocol/libraries/aave-upgradeability/VersionedInitializable.sol)
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
IERC1967 :
ERC-1967: Proxy Storage Slots. This interface contains the events defined in the ERC. _Available since v4.8.3._
AdminChanged(address,address) :
Emitted when the admin account has changed.
BeaconUpgraded(address) :
Emitted when the beacon is changed.
Upgraded(address) :
Emitted when the implementation is upgraded.
Clones :
https://eips.ethereum.org/EIPS/eip-1167[EIP 1167] is a standard for deploying minimal proxy contracts, also known as "clones". > To simply and cheaply clone contract functionality in an immutable way, this standard specifies > a minimal bytecode implementation that delegates all calls to a known, fixed address. The library includes functions to deploy a proxy using either `create` (traditional deployment) or `create2` (salted deterministic deployment). It also includes functions to predict the addresses of clones deployed using the deterministic method. _Available since v3.4._
ERC1967Proxy :
This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the implementation behind the proxy.
constructor :
Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor.
ERC1967Upgrade :
This abstract contract provides getters and event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. _Available since v4.1._
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
IBeacon :
This is the interface that {BeaconProxy} expects of its beacon.
implementation() :
Must return an address that can be used as a delegate call target. {BeaconProxy} will check that this address is a contract.
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721Receiver.onERC721Received.selector`.
IERC721Enumerable :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
Address :
Collection of functions related to the address type
Base64 :
Provides a set of functions to operate with Base64 strings. _Available since v4.5._
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
Strings :
String operations.
ERC165 :
Implementation of the {IERC165} interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: ```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ``` Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Math :
Standard math utilities missing in the Solidity language.
SignedMath :
Standard signed math utilities missing in the Solidity language.
CollectNFT.sol
FollowNFT.sol
LensHub.sol
ERC721Enumerable.sol
ERC721Time.sol
IERC721Time.sol
LensMultiState.sol
LensNFTBase.sol
FeeModuleBase.sol
FollowValidationModuleBase.sol
ModuleBase.sol
ModuleGlobals.sol
FeeCollectModule.sol
FreeCollectModule.sol
LimitedFeeCollectModule.sol
LimitedTimedFeeCollectModule.sol
RevertCollectModule.sol
TimedFeeCollectModule.sol
ApprovalFollowModule.sol
FeeFollowModule.sol
FollowValidatorFollowModuleBase.sol
ProfileFollowModule.sol
RevertFollowModule.sol
FollowerOnlyReferenceModule.sol
LensHubStorage.sol
ICollectModule.sol
ICollectNFT.sol
IFollowModule.sol
IFollowNFT.sol
ILensHub.sol
ILensNFTBase.sol
IModuleGlobals.sol
IReferenceModule.sol
Constants.sol
DataTypes.sol
Errors.sol
Events.sol
Helpers.sol
InteractionLogic.sol
ProfileTokenURILogic.sol
PublishingLogic.sol
AccessControlV1.sol
AccessControlV2.sol
LensPeriphery.sol
ProfileCreationProxy.sol
UIDataProvider.sol
Currency.sol
Helper.sol
MockAccessControlV2BadRevision.sol
MockFollowModule.sol
MockLensHubV2.sol
MockLensHubV2BadRevision.sol
MockLensHubV2Storage.sol
MockProfileCreationProxy.sol
MockReferenceModule.sol
FollowNFTProxy.sol
TransparentUpgradeableProxy.sol
VersionedInitializable.sol
Ownable.sol
IERC1967.sol
draft-IERC1822.sol
Clones.sol
ERC1967Proxy.sol
ERC1967Upgrade.sol
Proxy.sol
IBeacon.sol
ERC20.sol
IERC20.sol
IERC20Metadata.sol
IERC20Permit.sol
SafeERC20.sol
IERC721.sol
IERC721Receiver.sol
IERC721Enumerable.sol
IERC721Metadata.sol
Address.sol
Base64.sol
Context.sol
StorageSlot.sol
Strings.sol
ERC165.sol
IERC165.sol
Math.sol
SignedMath.sol

113 downloads

Chains

Authors

Lens Protocol
  • Social
  • Protocol
Info
Docs
Source
ChefGPT
Expand
Share

Get Cookin'

113 downloads

Chains

Authors

     &&&&&                        &&&&&&&&&&&&&&&&&&&&&&&&     &&&&&&&&&&              &&&&&         /&&&&&&&&&&&&&&&&&           
     &&&&&                        &&&&&&&&&&&&&&&&&&&&&&&&     &&&&  &&&&&             &&&&&       &&&&&&(        .&&&&&&*        
     &&&&&                        &&&&&                        &&&&   &&&&&            &&&&&      &&&&/               &&&&&       
     &&&&&                        &&&&&                        &&&&    &&&&&           &&&&&     &&&&&                 &&&&,      
     &&&&&                        &&&&&                        &&&&     &&&&&          &&&&&     &&&&&                 &&&&&      
     &&&&&                        &&&&&                        &&&&      &&&&&         &&&&&      &&&&&&                          
     &&&&&                        &&&&&                        &&&&       &&&&%        &&&&&        &&&&&&&&&&&                   
     &&&&&                        &&&&&&&&&&&&&&&&&&&&         &&&&        &&&&/       &&&&&             &&&&&&&&&&&&&&           
     &&&&&                        &&&&&                        &&&&         &&&&*      &&&&&                     ,&&&&&&&&        
     &&&&&                        &&&&&                        &&&&          &&&&      &&&&&                          (&&&&&      
     &&&&&                        &&&&&                        &&&&           &&&&     &&&&&    &&&&&                   &&&&      
     &&&&&                        &&&&&                        &&&&            &&&&    &&&&&     &&&&                   &&&&      
     &&&&&                        &&&&&                        &&&&            *&&&&   &&&&&     /&&&&&                &&&&&      
     &&&&&&&&&&&&&&&&&&&&&&&&&    &&&&&&&&&&&&&&&&&&&&&&&&     &&&&             (&&&&  &&&&&       &&&&&&&         &&&&&&&        
     &&&&&&&&&&&&&&&&&&&&&&&&&    &&&&&&&&&&&&&&&&&&&&&&&&     &&&&              %&&&&&&&&&&          &&&&&&&&&&&&&&&&&,          
                                                                                                                                  
                                                                                                                                  
                                                                                                                                  

                  _( )_      _                  wWWWw   _                        _( )_      _                  wWWWw   _       
      @@@@       (_   _)    ( )     _     @@@@  (___) _( )_          @@@@       (_   _)    ( )     _     @@@@  (___) _( )_     
     @@()@@ wWWWw  (_)\     ( )   _( )_  @@()@@   Y  (_   _)        @@()@@ wWWWw  (_)\     ( )   _( )_  @@()@@   Y  (_   _)    
      @@@@  (___)      |/   ( )  (_____)  @@@@   \|/   (_)\          @@@@  (___)      |/   ( )  (_____)  @@@@   \|/   (_)\      
       /      Y       \|    (_)     |     \|      |/       |          /      Y       \|    (_)     |     \|      |/      |     
    \ |      \|/       | / \ | /   \|/      |/    \       \|/      \ |      \|/       | / \ | /   \|/      |/    \       \|/   
      |       |        |     |      |       |     |        |         |       |        |     |      |       |     |        |    
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   _//|\_     |        |\ _//|\_   /|\      |\_   |\___    |\     _//|\_     |        |\ _//|\_   /|\      |\_   |\___    |\   
      | \_/  / \__    / \_   |        \   _/      |       _|         | \_/  / \__    / \_   |        \   _/      |       _|    
     /|\_  _/       _/\       \__     /\_        / \_      |_       /|\_  _/       _/\       \__     /\_        / \_      |_    
    / |     |        \___      \_     /\         \        /        / |     |        \___      \_     /\         \        /                         

Lens Protocol

The Lens Protocol is a decentralized, non-custodial social graph. Lens implements unique, on-chain social interaction mechanisms analogous to commonly understood Web2 social media interactions, but significantly expanded with unique functionality that empower communities to form and participants to own their own social graph.

Setup

For now only Linux and macOS are known to work

We are now figuring out what works for Windows, instructions will be updated soon

(feel free to experiment and submit PR's)

The environment is built using Docker Compose, note that your .env file must have the RPC URL of the network you want to use, and an optional MNEMONIC and BLOCK_EXPLORER_KEY, defined like so, assuming you choose to use Mumbai network:

MNEMONIC="MNEMONIC YOU WANT TO DERIVE WALLETS FROM HERE"
MUMBAI_RPC_URL="YOUR RPC URL HERE"
BLOCK_EXPLORER_KEY="YOUR BLOCK EXPLORER API KEY HERE"

With the environment file set up, you can move on to using Docker:

export USERID=$UID && docker-compose build && docker-compose run --name lens contracts-env bash

If you need additional terminals:

docker exec -it lens bash

From there, have fun!

Here are a few self-explanatory scripts:

npm run test
npm run coverage
npm run compile

Cleanup leftover Docker containers:

USERID=$UID docker-compose down

Protocol Overview

The Lens Protocol transfers ownership of social graphs to the participants of that graph themselves. This is achieved by creating direct links between profiles and their followers, while allowing fine-grained control of additional logic, including monetization, to be executed during those interactions on a profile-by-profile basis.

Here's how it works...

Profiles

Any address can create a profile and receive an ERC-721 Lens Profile NFT. Profiles are represented by a ProfileStruct:

/**
 * @notice A struct containing profile data.
 *
 * @param pubCount The number of publications made to this profile.
 * @param followNFT The address of the followNFT associated with this profile, can be empty..
 * @param followModule The address of the current follow module in use by this profile, can be empty.
 * @param handle The profile's associated handle.
 * @param uri The URI to be displayed for the profile NFT.
 */
struct ProfileStruct {
    uint256 pubCount;
    address followNFT;
    address followModule;
    string handle;
    string uri;
}

Profiles have a specific URI associated with them, which is meant to include metadata, such as a link to a profile picture or a display name for instance, the JSON standard for this URI is not yet determined. Profile owners can always change their follow module or profile URI.

Publications

Profile owners can publish to any profile they own. There are three publication types: Post, Comment and Mirror. Profile owners can also set and initialize the Follow Module associated with their profile.

Publications are on-chain content created and published via profiles. Profile owners can create (publish) three publication types, outlined below. They are represented by a PublicationStruct:

/**
 * @notice A struct containing data associated with each new publication.
 *
 * @param profileIdPointed The profile token ID this publication points to, for mirrors and comments.
 * @param pubIdPointed The publication ID this publication points to, for mirrors and comments.
 * @param contentURI The URI associated with this publication.
 * @param referenceModule The address of the current reference module in use by this profile, can be empty.
 * @param collectModule The address of the collect module associated with this publication, this exists for all publication.
 * @param collectNFT The address of the collectNFT associated with this publication, if any.
 */
struct PublicationStruct {
    uint256 profileIdPointed;
    uint256 pubIdPointed;
    string contentURI;
    address referenceModule;
    address collectModule;
    address collectNFT;
}

Publication Types

Post

This is the standard publication type, akin to a regular post on traditional social media platforms. Posts contain:

  1. A URI, pointing to the actual publication body's metadata JSON, including any images or text.
  2. An uninitialized pointer, since pointers are only needed in mirrors and comments.
Comment

This is a publication type that points back to another publication, whether it be a post, comment or mirror, akin to a regular comment on traditional social media. Comments contain:

  1. A URI, just like posts, pointing to the publication body's metadata JSON.
  2. An initialized pointer, containing the profile ID and the publication ID of the publication commented on.
Mirror

This is a publication type that points to another publication, note that mirrors cannot, themselves, be mirrored (doing so instead mirrors the pointed content). Mirrors have no original content of its own. Akin to a "share" on traditional social media. Mirrors contain:

  1. An empty URI, since they cannot have content associated with them.
  2. An initialized pointer, containing the profile ID and the publication ID of the mirrored publication.

Profile Interaction

There are two types of profile interactions: follows and collects.

Follows

Wallets can follow profiles, executing modular follow processing logic (in that profile's selected follow module) and receiving a Follow NFT. Each profile has a connected, unique FollowNFT contract, which is first deployed upon successful follow. Follow NFTs are NFTs with integrated voting and delegation capability.

The inclusion of voting and delegation right off the bat means that follow NFTs have the built-in capability to create a spontaneous DAO around any profile. Furthermore, holding follow NFTs allows followers to collect publications from the profile they are following (except mirrors, which are equivalent to shares in Web2 social media, and require following the original publishing profile to collect).

Collects

Collecting works in a modular fashion as well, every publication (except mirrors) requires a Collect Module to be selected and initialized. This module, similarly to follow modules, can contain any arbitrary logic to be executed upon collects. Successful collects result in a new, unique NFT being minted, essentially as a saved copy of the original publication. There is one deployed collect NFT contract per publication, and it's deployed upon the first successful collect.

When a mirror is collected, what happens behind the scenes is the original, mirrored publication is collected, and the mirror publisher's profile ID is passed as a "referrer." This allows neat functionality where collect modules that incur a fee can, for instance, reward referrals. Note that the Collected event, which is emitted upon collection, indexes the profile and publication directly being passed, which, in case of a mirror, is different than the actual original publication getting collected (which is emitted unindexed).

Alright, that was a mouthful! Let's move on to more specific details about Lens's core principle: Modularity.

Lens Modularity

Stepping back for a moment, the core concept behind modules is to allow as much freedom as possible to the community to come up with new, innovative interaction mechanisms between social graph participants. For security purposes, this is achieved by including a whitelisted list of modules controlled by governance.

To recap, the Lens Protocol has three types of modules:

  1. Follow Modules contain custom logic to be executed upon follow.
  2. Collect Modules contain custom logic to be executed upon collect. Typically, these modules include at least a check that the collector is a follower.
  3. Reference Modules contain custom logic to be executed upon comment and mirror. These modules can be used to limit who is able to comment and interact with a profile.

Note that collect and reference modules should not assume that a publication cannot be re-initialized, and thus should include front-running protection as a security measure if needed, as if the publication data was not static. This is even more prominent in follow modules, where it can absolutely be changed for a given profile.

Lastly, there is also a ModuleGlobals contract which acts as a central data provider for modules. It is controlled by a specific governance address which can be set to a different executor compared to the Hub's governance. It's expected that modules will fetch dynamically changing data, such as the module globals governance address, the treasury address, the treasury fee as well as a list of whitelisted currencies.

Upgradeability

This iteration of the Lens Protocol implements a transparent upgradeable proxy for the central hub to be controlled by governance. There are no other aspects of the protocol that are upgradeable. In an ideal world, the hub will not require upgrades due to the system's inherent modularity and openness, upgradeability is there only to implement new, breaking changes that would be impossible, or unreasonable to implement otherwise.

This does come with a few caveats, for instance, the ModuleGlobals contract implements a currency whitelist, but it is not upgradeable, so the "removal" of a currency whitelist in a module would require a specific new module that does not query the ModuleGlobals contract for whitelisted currencies.

Lens Protocol is a composable and decentralized social graph, ready for you to build on so you can focus on creating a great experience, not scaling your users.
ERC721Enumerable :
This implements an optional extension of {ERC721} defined in the EIP that adds enumerability of all the token ids in the contract as well as all token ids owned by each account. NOTE: Modified from Openzeppelin to inherit from a modified ERC721 contract.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
ERC721Time :
Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including the Metadata extension, but not including the Enumerable extension, which is available separately as {ERC721Enumerable}. Modifications: 1. Refactored _operatorApprovals setter into an internal function to allow meta-transactions. 2. Constructor replaced with an initializer. 3. Mint timestamp is now stored in a TokenData struct alongside the owner address.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
InteractionLogic :
The functions are external, so they are called from the hub via `delegateCall` under the hood.
PublishingLogic :
The functions are external, so they are called from the hub via `delegateCall` under the hood. Furthermore, expected events are emitted from this library instead of from the hub to alleviate code size concerns.
createComment(DataTypes.CommentData,uint256,mapping(uint256 => DataTypes.ProfileStruct) storage,mapping(uint256 => mapping(uint256 => DataTypes.PublicationStruct)) storage,mapping(address => bool) storage,mapping(address => bool) storage) :
This function is unique in that it requires many variables, so, unlike the other publishing functions, we need to pass the full CommentData struct in memory to avoid a stack too deep error.
createPost(uint256,string,address,bytes,address,bytes,uint256,mapping(uint256 => mapping(uint256 => DataTypes.PublicationStruct)) storage,mapping(address => bool) storage,mapping(address => bool) storage) :
To avoid a stack too deep error, reference parameters are passed in memory rather than calldata.
LensPeriphery :
This is useful because it allows clients to filter out follow NFTs that were transferred to a recipient by another user (i.e. Not a mint) and not register them as "following" unless the recipient explicitly toggles the follow here.
UIDataProvider :
This is a helper contract to fetch a profile and its latest publication in a single call.
Helper :
This is a helper contract used for internal testing. NOTE: This contract is not meant to be deployed and is unsafe for use.
batchDelegate(address,address,address) :
This is a helper function to aid in testing same-block delegation in the FollowNFT contract.
getBlockNumber() :
This is a helper function that exposes the block number due to the inconsistency of fetching the block number from scripts.
MockLensHubV2 :
A mock upgraded LensHub contract that is used mainly to validate that the initializer works as expected and that the storage layout after an upgrade is valid.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
MockLensHubV2BadRevision :
A mock upgraded LensHub contract that is used to validate that the initializer cannot be called with the same revision.
approve(address,uint256) :
See {IERC721-approve}.
balanceOf(address) :
See {IERC721-balanceOf}.
exists(uint256) :
See {IERC721Time-exists}
getApproved(uint256) :
See {IERC721-getApproved}.
isApprovedForAll(address,address) :
See {IERC721-isApprovedForAll}.
mintTimestampOf(uint256) :
See {IERC721Time-mintTimestampOf}
name() :
See {IERC721Metadata-name}.
ownerOf(uint256) :
See {IERC721-ownerOf}.
safeTransferFrom(address,address,uint256) :
See {IERC721-safeTransferFrom}.
safeTransferFrom(address,address,uint256,bytes) :
See {IERC721-safeTransferFrom}.
setApprovalForAll(address,bool) :
See {IERC721-setApprovalForAll}.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
symbol() :
See {IERC721Metadata-symbol}.
tokenByIndex(uint256) :
See {IERC721Enumerable-tokenByIndex}.
tokenDataOf(uint256) :
See {IERC721Time-mintTimestampOf}
tokenOfOwnerByIndex(address,uint256) :
See {IERC721Enumerable-tokenOfOwnerByIndex}.
tokenURI(uint256) :
See {IERC721Metadata-tokenURI}.
totalSupply() :
See {IERC721Enumerable-totalSupply}.
transferFrom(address,address,uint256) :
See {IERC721-transferFrom}.
TransparentUpgradeableProxy :
This contract implements a proxy that is upgradeable by an admin. To avoid https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357[proxy selector clashing], which can potentially be used in an attack, this contract uses the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[transparent proxy pattern]. This pattern implies two things that go hand in hand: 1. If any account other than the admin calls the proxy, the call will be forwarded to the implementation, even if that call matches one of the admin functions exposed by the proxy itself. 2. If the admin calls the proxy, it can access the admin functions, but its calls will never be forwarded to the implementation. If the admin tries to call a function on the implementation it will fail with an error that says "admin cannot fallback to proxy target". These properties mean that the admin account can only be used for admin actions like upgrading the proxy or changing the admin, so it's best if it's a dedicated account that is not used for anything else. This will avoid headaches due to sudden errors when trying to call a function from the proxy implementation. Our recommendation is for the dedicated account to be an instance of the {ProxyAdmin} contract. If set up this way, you should think of the `ProxyAdmin` instance as the real administrative interface of your proxy.
admin() :
Returns the current admin. NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyAdmin}. TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`
changeAdmin(address) :
Changes the admin of the proxy. Emits an {AdminChanged} event. NOTE: Only the admin can call this function. See {ProxyAdmin-changeProxyAdmin}.
constructor :
Initializes an upgradeable proxy managed by `_admin`, backed by the implementation at `_logic`, and optionally initialized with `_data` as explained in {ERC1967Proxy-constructor}.
implementation() :
Returns the current implementation. NOTE: Only the admin can call this function. See {ProxyAdmin-getProxyImplementation}. TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call. `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
upgradeTo(address) :
Upgrade the implementation of the proxy. NOTE: Only the admin can call this function. See {ProxyAdmin-upgrade}.
upgradeToAndCall(address,bytes) :
Upgrade the implementation of the proxy, and then call a function from the new implementation as specified by `data`, which should be an encoded function call. This is useful to initialize new storage variables in the proxied contract. NOTE: Only the admin can call this function. See {ProxyAdmin-upgradeAndCall}.
VersionedInitializable :
Helper contract to implement initializer functions. To use it, replace the constructor with a function that has the `initializer` modifier. WARNING: Unlike constructors, initializer functions must be manually invoked. This applies both to deploying an Initializable contract, as well as extending an Initializable contract via inheritance. WARNING: When used with inheritance, manual care must be taken to not invoke a parent initializer twice, or ensure that all initializers are idempotent, because this is not dealt with automatically as with constructors. This is slightly modified from [Aave's version.](https://github.com/aave/protocol-v2/blob/6a503eb0a897124d8b9d126c915ffdf3e88343a9/contracts/protocol/libraries/aave-upgradeability/VersionedInitializable.sol)
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
IERC1967 :
ERC-1967: Proxy Storage Slots. This interface contains the events defined in the ERC. _Available since v4.8.3._
AdminChanged(address,address) :
Emitted when the admin account has changed.
BeaconUpgraded(address) :
Emitted when the beacon is changed.
Upgraded(address) :
Emitted when the implementation is upgraded.
Clones :
https://eips.ethereum.org/EIPS/eip-1167[EIP 1167] is a standard for deploying minimal proxy contracts, also known as "clones". > To simply and cheaply clone contract functionality in an immutable way, this standard specifies > a minimal bytecode implementation that delegates all calls to a known, fixed address. The library includes functions to deploy a proxy using either `create` (traditional deployment) or `create2` (salted deterministic deployment). It also includes functions to predict the addresses of clones deployed using the deterministic method. _Available since v3.4._
ERC1967Proxy :
This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the implementation behind the proxy.
constructor :
Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor.
ERC1967Upgrade :
This abstract contract provides getters and event emitting update functions for https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. _Available since v4.1._
Proxy :
This abstract contract provides a fallback function that delegates all calls to another contract using the EVM instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to be specified by overriding the virtual {_implementation} function. Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a different contract through the {_delegate} function. The success and return data of the delegated call will be returned back to the caller of the proxy.
IBeacon :
This is the interface that {BeaconProxy} expects of its beacon.
implementation() :
Must return an address that can be used as a delegate call target. {BeaconProxy} will check that this address is a contract.
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20Permit :
Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in https://eips.ethereum.org/EIPS/eip-2612[EIP-2612]. Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't need to send a transaction, and thus is not required to hold Ether at all.
DOMAIN_SEPARATOR() :
Returns the domain separator used in the encoding of the signature for {permit}, as defined by {EIP712}.
nonces(address) :
Returns the current nonce for `owner`. This value must be included whenever a signature is generated for {permit}. Every successful call to {permit} increases ``owner``'s nonce by one. This prevents a signature from being used multiple times.
permit(address,address,uint256,uint256,uint8,bytes32,bytes32) :
Sets `value` as the allowance of `spender` over ``owner``'s tokens, given ``owner``'s signed approval. IMPORTANT: The same issues {IERC20-approve} has related to transaction ordering also apply here. Emits an {Approval} event. Requirements: - `spender` cannot be the zero address. - `deadline` must be a timestamp in the future. - `v`, `r` and `s` must be a valid `secp256k1` signature from `owner` over the EIP712-formatted function arguments. - the signature must use ``owner``'s current nonce (see {nonces}). For more information on the signature format, see the https://eips.ethereum.org/EIPS/eip-2612#specification[relevant EIP section].
SafeERC20 :
Wrappers around ERC20 operations that throw on failure (when the token contract returns false). Tokens that return no value (and instead revert or throw on failure) are also supported, non-reverting calls are assumed to be successful. To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract, which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
IERC721 :
Required interface of an ERC721 compliant contract.
Approval(address,address,uint256) :
Emitted when `owner` enables `approved` to manage the `tokenId` token.
ApprovalForAll(address,address,bool) :
Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
Transfer(address,address,uint256) :
Emitted when `tokenId` token is transferred from `from` to `to`.
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Receiver :
Interface for any contract that wants to support safeTransfers from ERC721 asset contracts.
onERC721Received(address,address,uint256,bytes) :
Whenever an {IERC721} `tokenId` token is transferred to this contract via {IERC721-safeTransferFrom} by `operator` from `from`, this function is called. It must return its Solidity selector to confirm the token transfer. If any other value is returned or the interface is not implemented by the recipient, the transfer will be reverted. The selector can be obtained in Solidity with `IERC721Receiver.onERC721Received.selector`.
IERC721Enumerable :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
tokenByIndex(uint256) :
Returns a token ID at a given `index` of all the tokens stored by the contract. Use along with {totalSupply} to enumerate all tokens.
tokenOfOwnerByIndex(address,uint256) :
Returns a token ID owned by `owner` at a given `index` of its token list. Use along with {balanceOf} to enumerate all of ``owner``'s tokens.
totalSupply() :
Returns the total amount of tokens stored by the contract.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
IERC721Metadata :
See https://eips.ethereum.org/EIPS/eip-721
approve(address,uint256) :
Gives permission to `to` to transfer `tokenId` token to another account. The approval is cleared when the token is transferred. Only a single account can be approved at a time, so approving the zero address clears previous approvals. Requirements: - The caller must own the token or be an approved operator. - `tokenId` must exist. Emits an {Approval} event.
balanceOf(address) :
Returns the number of tokens in ``owner``'s account.
getApproved(uint256) :
Returns the account approved for `tokenId` token. Requirements: - `tokenId` must exist.
isApprovedForAll(address,address) :
Returns if the `operator` is allowed to manage all of the assets of `owner`. See {setApprovalForAll}
name() :
Returns the token collection name.
ownerOf(uint256) :
Returns the owner of the `tokenId` token. Requirements: - `tokenId` must exist.
safeTransferFrom(address,address,uint256) :
Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
safeTransferFrom(address,address,uint256,bytes) :
Safely transfers `tokenId` token from `from` to `to`. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must exist and be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer. Emits a {Transfer} event.
setApprovalForAll(address,bool) :
Approve or remove `operator` as an operator for the caller. Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller. Requirements: - The `operator` cannot be the caller. Emits an {ApprovalForAll} event.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
symbol() :
Returns the token collection symbol.
tokenURI(uint256) :
Returns the Uniform Resource Identifier (URI) for `tokenId` token.
transferFrom(address,address,uint256) :
Transfers `tokenId` token from `from` to `to`. WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721 or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must understand this adds an external call which potentially creates a reentrancy vulnerability. Requirements: - `from` cannot be the zero address. - `to` cannot be the zero address. - `tokenId` token must be owned by `from`. - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}. Emits a {Transfer} event.
Address :
Collection of functions related to the address type
Base64 :
Provides a set of functions to operate with Base64 strings. _Available since v4.5._
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
StorageSlot :
Library for reading and writing primitive types to specific storage slots. Storage slots are often used to avoid storage conflict when dealing with upgradeable contracts. This library helps with reading and writing to such slots without the need for inline assembly. The functions in this library return Slot structs that contain a `value` member that can be used to read or write. Example usage to set ERC1967 implementation slot: ```solidity contract ERC1967 { bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; function _getImplementation() internal view returns (address) { return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; } function _setImplementation(address newImplementation) internal { require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; } } ``` _Available since v4.1 for `address`, `bool`, `bytes32`, `uint256`._ _Available since v4.9 for `string`, `bytes`._
Strings :
String operations.
ERC165 :
Implementation of the {IERC165} interface. Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check for the additional interface id that will be supported. For example: ```solidity function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) { return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId); } ``` Alternatively, {ERC165Storage} provides an easier to use but more expensive implementation.
supportsInterface(bytes4) :
See {IERC165-supportsInterface}.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
Math :
Standard math utilities missing in the Solidity language.
SignedMath :
Standard signed math utilities missing in the Solidity language.
CollectNFT.sol
FollowNFT.sol
LensHub.sol
ERC721Enumerable.sol
ERC721Time.sol
IERC721Time.sol
LensMultiState.sol
LensNFTBase.sol
FeeModuleBase.sol
FollowValidationModuleBase.sol
ModuleBase.sol
ModuleGlobals.sol
FeeCollectModule.sol
FreeCollectModule.sol
LimitedFeeCollectModule.sol
LimitedTimedFeeCollectModule.sol
RevertCollectModule.sol
TimedFeeCollectModule.sol
ApprovalFollowModule.sol
FeeFollowModule.sol
FollowValidatorFollowModuleBase.sol
ProfileFollowModule.sol
RevertFollowModule.sol
FollowerOnlyReferenceModule.sol
LensHubStorage.sol
ICollectModule.sol
ICollectNFT.sol
IFollowModule.sol
IFollowNFT.sol
ILensHub.sol
ILensNFTBase.sol
IModuleGlobals.sol
IReferenceModule.sol
Constants.sol
DataTypes.sol
Errors.sol
Events.sol
Helpers.sol
InteractionLogic.sol
ProfileTokenURILogic.sol
PublishingLogic.sol
AccessControlV1.sol
AccessControlV2.sol
LensPeriphery.sol
ProfileCreationProxy.sol
UIDataProvider.sol
Currency.sol
Helper.sol
MockAccessControlV2BadRevision.sol
MockFollowModule.sol
MockLensHubV2.sol
MockLensHubV2BadRevision.sol
MockLensHubV2Storage.sol
MockProfileCreationProxy.sol
MockReferenceModule.sol
FollowNFTProxy.sol
TransparentUpgradeableProxy.sol
VersionedInitializable.sol
Ownable.sol
IERC1967.sol
draft-IERC1822.sol
Clones.sol
ERC1967Proxy.sol
ERC1967Upgrade.sol
Proxy.sol
IBeacon.sol
ERC20.sol
IERC20.sol
IERC20Metadata.sol
IERC20Permit.sol
SafeERC20.sol
IERC721.sol
IERC721Receiver.sol
IERC721Enumerable.sol
IERC721Metadata.sol
Address.sol
Base64.sol
Context.sol
StorageSlot.sol
Strings.sol
ERC165.sol
IERC165.sol
Math.sol
SignedMath.sol