Address Lock Overview

The 2nd most powerful tool in the Revest arsenal

This document references documents from the Revest Protocol API

Understanding Address Locks

The address lock is the most versatile of all locks offered by the Revest protocol, as it allows arbitrary addresses to function as locks on Revest's value storage mechanic. The address lock offers both push and pull functionality, and the acceptable form of address differs based on the schema chosen. No selection must be made by the end-user between schema when creating locks , only in choosing how they will interact with the Revest Protocol; neither schema is mutually exclusive for contracts, however, wallet addresses may only implement an unlocking schema based on push interactions.

Push Schema

With the push schema of address lock interactions, the address specified for the address lock is the only address which may unlock the address lock, by sending a transaction to the "unlock" method exposed by IRevest.sol. This is a positive form of address lock, meaning that an address lock using only this schema (a wallet address or a contract not implementing IAddressLock) will have to send a transaction to the Revest contract to withdraw from the address lock or to unlock it; other users may not passively coerce an address lock to unlock because certain conditions have been met, if that address lock is designed around a push schema. A diagram to detail this concept follows.

Pull Methodology

The pull methodology for address locks involves implementing the IAddressLock interface. This interface enables far more powerful features than the push methodology is capable of reaching by integrating automatic checking of the address lock directly into the Revest Protocol itself. Under this system, the Revest Protocol is capable of:

• Automatically collecting all inputs desired by the lock developer through the Revest Protocol frontend, with simply entering the contract address auto-generating an input form for the user to fill out

• Displaying unlocking conditions and their current on-chain state to the end-user via the Revest Info Panel

• Transmitting updates to the lock collected via a similar input form to the one utilized in minting, with desired inputs specified by the developer, all from the Revest Info Panel. No frontend development necessary.

• Automatically detecting and displaying if it possible to unlock the lock to the end-user via the FNFT itself and then allowing that user to unlock the lock directly from the Revest Info Panel

• Allowing the end-user to unlock the lock during a withdrawal operation if the conditions needed to cause unlocking are met; no third-party transactions needed.

All of the information needed for the Revest Protocol and the Address Lock to properly communicate is described by the Address Lock Metadata File, described on the following page.