You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A pattern that we see frequently is one where platforms want to restrict the calls that can be done to a lock deployed by them on behalf of their users. It is possible to achieve this by creating a "proxy lock manager" contract.
This contract has the purpose of deploying locks for which it will be lock manager, as well as relay calls to the lock, if an only if the sender of the message is "authorized" to do that.
As such, this contract will have 2 main functions:
a function to deploy (and possibly) configure locks: deployLock
a function to perform actions on this lock, provided that they are sent by an "approved" user for that lock.
It will also include a function to add/revoke new approved users for specific locks (and a structure to keep track of these, probably a mapping of lock addresses to approved addresses).
Deploying locks
For this, we should implement createUpgradableLockAtVersion in a deployLock function. This function should probably take the same params as createUpgradableLockAtVersion (example here). However, it is important that the proxy contract sets itself as lock manager, and not the caller of deployLock. The deployLock should "store" the address of the approved user for the newly created lock.
Performing actions
There, the proxy should also have a callLock function which takes 3 arguments:
the lock's address
the full calldata of a call on the lock (method + arguments)
a signature of the previous argument performed by the approved user
The function callLock should then recover the signer of the calldata and verify that indeed the signer is an approved user. If not, the function should revert callLock should then verify that the calldata is for a method that is "allowed". If not the function should revert
Finally callLock will execute the function call on the lock!
The text was updated successfully, but these errors were encountered:
A pattern that we see frequently is one where platforms want to restrict the calls that can be done to a lock deployed by them on behalf of their users. It is possible to achieve this by creating a "proxy lock manager" contract.
This contract has the purpose of deploying locks for which it will be lock manager, as well as relay calls to the lock, if an only if the sender of the message is "authorized" to do that.
As such, this contract will have 2 main functions:
deployLock
It will also include a function to add/revoke new approved users for specific locks (and a structure to keep track of these, probably a mapping of lock addresses to approved addresses).
Deploying locks
For this, we should implement
createUpgradableLockAtVersion
in adeployLock
function. This function should probably take the same params ascreateUpgradableLockAtVersion
(example here). However, it is important that the proxy contract sets itself as lock manager, and not the caller ofdeployLock
. ThedeployLock
should "store" the address of the approved user for the newly created lock.Performing actions
There, the proxy should also have a
callLock
function which takes 3 arguments:calldata
of a call on the lock (method + arguments)The function
callLock
should then recover the signer of thecalldata
and verify that indeed the signer is an approved user. If not, the function should revertcallLock
should then verify that thecalldata
is for a method that is "allowed". If not the function should revertFinally
callLock
will execute the function call on the lock!The text was updated successfully, but these errors were encountered: