Keyring Guard
Description
The Keyring Guard is created by Keyring but deployed and owned by you, like a drag-and-drop solution ready to be used on the functions you want to gate.
Integration
Wrap your contract in the Guard interface and use the modifier
to guard relevant functions.
It is recommended to query Keyring live vs. storing data in a local mapping as a wallet/user could become red-flagged at any point in time and keeping the local storage in sync with Keyring's one would result in a bigger gas expense.
Illustration
Schematically, it works like this (expanding from Step 8️⃣ in the Data Flow):
Integration Example
We showcase an example of Keyring Guard integration into a Uniswap V4 permissioned pool.
See the repository here.
Firstly, import the relevant contracts and libraries from both Uniswap V4 and .
Then, extend the contract to inherit from the KeyringGuard
interface.
During the initialisation phase within the constructor, the contract needs to store the address of the KeyringGuard
deployed on the local chain.
Finally, the contract has to update (or override) any function to be permissioned, the getHooksCalls
function in this case. In the Uniswap V4 context, this override is necessary to specify which lifecycle hooks the contract intends to intercept. For example, the beforeSwap
hook is activated to impose restrictions on swap operations, effectively guarding the hook system to enforce authorisation checks.
Lastly, the authorisation logic is implemented within the updated/overridden function. By invoking the keyringGuard.isAuthorized
function, the contract verifies whether the caller is authorised to perform a swap operation. This mechanism ensures that unverified users are prevented from executing swaps.
Last updated