RegistryDeployer
script.
You can follow along our guide for using this script.
registerModule
function from the ModuleKit.
If you are using cast, you can use the following command:
MODULE_ADDRESS
, METADATA
, RESOLVER_CONTEXT
, RPC_URL
, and PRIVATE_KEY
with the appropriate values. Note that METADATA
and RESOLVER_CONTEXT
can be empty (0x
).
mockAttestToModule
function from the ModuleKit. To see how you can set up the script and run it, check out our guide for using forge script script.
If you are using cast, you can use the following command:
MODULE_ADDRESS
, ATTESTATION_DATA
, MODDULE_TYPES
, RPC_URL
, and PRIVATE_KEY
with the appropriate values. Note that ATTESTATION_DATA
can be empty (0x
) or a random data string since this is for mock purposes only. MODULE_TYPES
is an array of the types of the module, such as [1,2]
for a module that is a validator and an executor.
isModuleAttestedMock
function from the ModuleKit. If the module is attested, the function will return true
.
If you are using cast, you can use the following command:
MODULE_ADDRESS
and RPC_URL
with the appropriate values. If the module is attested, the output will non-zero data. Otherwise, it will be all zeros.
0xaed4d8baa80948d54d33de041513d30124e1ae3f
.
How exactly you set this up will depend on the account used, but most accounts have a way to supply trusted attesters on account initialization. You can also set this up manually by calling the trustAttesters
function on the Module Registry. To do this, you can create a new UserOperation with the target as the Module Registry (0x000000000069E2a187AEFFb852bF3cCdC95151B2
) and the call data as the trustAttesters
function (trustAttesters(uint8 threshold, address[] calldata attesters)
). In this case, you would use a threshold of 1 and the attester address being 0xaed4d8baa80948d54d33de041513d30124e1ae3f
.