IAddressLock API

The commented source code for the IAddressLock API may be found on this page

Implementing

Contract desiring to implement IAddressLock must implement the interface and all of its methods, inherit from OpenZeppelin ERC165, and include the following code to specify that they implement IAddressLock in the manner prescribed by EIP-165:

function supportsInterface(bytes4 interfaceId) public view override(ERC165, IERC165) returns (bool) {
    return interfaceId == type(IAddressLock).interfaceId
        || super.supportsInterface(interfaceId);
}

Methods

CreateLock

function createLock(uint fnftId, uint lockId, bytes memory arguments) external;

Parameters

• fnftId: the unique FNFT ID that represents the configuration for an FNFT series stored on that ID - this is not recommended as the primary manner to store data about an address lock in-contract with, as this is changed by splitting and additional deposit operations.

• lockId: the unique lock ID that corresponds to a unique lock configuration. This remains static across splits and additional deposit operations and should be the standard index used to map data about an individual lock. Under the hood, multiple FNFT IDs may map to the same lock ID; the inverse is never true.

• arguments: A bytes array representing the ABI Encoded parameters that need to be decoded and utilized in lock creation. These parameters are typically encoded on the frontend in the order specified by the Address Lock Metadata File.

Description

This method is called during the FNFT creation process by the Revest entry point contract. When the mintAddressLock function is called on the main Revest contract with a contract implementing IAddressLock as the trigger, it will call this function and pass through the input bytes array given to mintAddressLock as a parameter.

Developers should utilize this method to decode the arguments encoded in the bytes object with the ABI decoder.

(uint exValue1, string memory exValue2 ...) = abi.decode(arguments, (uint, string, ...));

Following this, developers should perform the desired storage operations for mapping of this custom data to the LockID passed in. Use of structs is suggested to optimize storage operations.

Example in ComboLock.sol

UpdateLock

function updateLock(uint fnftId, uint lockId, bytes memory arguments) external;

Parameters

• fnftId: the unique FNFT ID that represents the configuration for an FNFT series stored on that ID - this is not recommended as the primary manner to store data about an address lock in-contract with, as this is changed by splitting and additional deposit operations.

• lockId: the unique lock ID that corresponds to a unique lock configuration. This remains static across splits and additional deposit operations and should be the standard index used to map data about an individual lock. Under the hood, multiple FNFT IDs may map to the same lock ID; the inverse is never true.

• arguments: A bytes array representing the ABI Encoded parameters that need to be decoded and utilized in lock creation. These parameters are typically encoded on the frontend in the order specified by the Address Lock Metadata File.

Description

This method may be called at any time by the user during the lock's lifetime, both when the lock is unlocked and while the lock remains locked. Initially designed solely to facilitate the updating of on-chain oracles, this method's true potential lies in allowing interactions with locked-value without necessitating the withdrawal of the FNFT. Particularly in cases where a contract implements both IAddressLock and IOutputReceiver, this method allows for arbitrary interactions. Arguments sent to this method may be composed with different inputs than the minting inputs via the Address Lock Metadata File.

Example in Staking.sol demonstrating mid-lock interactions

IsUnlockable

function isUnlockable(uint fnftId, uint lockId) external view returns (bool);

Parameters

• fnftId: the unique FNFT ID that represents the configuration for an FNFT series stored on that ID - this is not recommended as the primary manner to store data about an address lock in-contract with, as this is changed by splitting and additional deposit operations.

• lockId: the unique lock ID that corresponds to a unique lock configuration. This remains static across splits and additional deposit operations and should be the standard index used to map data about an individual lock. Under the hood, multiple FNFT IDs may map to the same lock ID; the inverse is never true.

• returns: a boolean value representing whether the lock is able to be unlocked or not

Description

This method is called by the LockManager during an attempted withdrawal operation and will permit the withdrawal to continue if this method returns true. The core operations on any lock-specific data stored in the IAddressLock implementation should be called and checked within this method.

Example in SupplyLock.sol

GetDisplayValues

function getDisplayValues(uint fnftId, uint lockId) external view returns (bytes memory);

Parameters

• fnftId: the unique FNFT ID that represents the configuration for an FNFT series stored on that ID - this is not recommended as the primary manner to store data about an address lock in-contract with, as this is changed by splitting and additional deposit operations.

• lockId: the unique lock ID that corresponds to a unique lock configuration. This remains static across splits and additional deposit operations and should be the standard index used to map data about an individual lock. Under the hood, multiple FNFT IDs may map to the same lock ID; the inverse is never true.

• returns: a bytes array that contains the ABI encoded values the lock developer desires to display on the frontend Info Panel for a given FNFT

Description

This method is called by the frontend to retrieve an ABI encoded bytes object representing a series of parameters that the developer of the lock desires to display to the end-user. The schema by which to decode these parameters is specified within the Address Lock Metadata File and is utilized by the frontend to retrieve and display up-to-date information to the end-user on the state of their FNFT's lock within the Info Panel.

Example in SupplyLock.sol to encode three values and transmit them to the frontend

GetMetadata

function getMetadata() external view returns (string memory);

Parameters

• returns: a string pointing to a URL (preferably, an IPFS one) where the metadata file for the Address Lock in question may be found

Description

This method points to where the metadata file for the Address Lock resides. It should be hosted somewhere that the URL is unlikely to change in the future, such as IPFS, to avoid breaking the ability for the frontend to properly collect and encode parameters for the Address Lock to properly function. This function is not mandatory, but is typically necessary for a generalizable Address Lock.

Example in ComboLock.sol

NeedsUpdate

function needsUpdate() external view returns (bool);

Parameters

• returns: a boolean value representing whether this lock should have the "update lock" button rendered on the frontend. This value being set to false will not inherently break the "updateLock" function, but it will disable the button to call that method from rendering on the Revest frontend.

Description

Purely a visual parameter, used only to direct the frontend to render the systems by which updates may be encoded and transmitted to the AddressLock from the Revest Info Panel.

Example in ComboLock.sol