Paymaster feature is currently in a limited access phase and only available by invite. If you’re interested in access, please contact us.
Click on “Add Policy” and follow the steps within the policy creation screen.
If you select the free plan, you will have unlimited access to sponsoring on testnets. Currently, only Sepolia is supported.
With the Pay-as-you-go plan, you will be asked to enter credit card information. You will not be billed immediately.
Instead you will be charged based on usage, with Paymaster Credits. This is calculated using a simple formula:
Billing occurs monthly; however, if a threshold of 100 USD is reached, an immediate charge will occur, and the billing cycle will reset.
All supported chains are enabled by default, but you can deselect any chain to sponsor transactions only on specific chains.
Policy logic can be updated in one of two ways:
There are distinct advantages to this:
Once created, the policy will become active immediately if the start date has already passed, making it ready for use.
All that is required is to
Sponsor Smart Account Deployment
checkbox.Based on EIP 5792 and ERC 7677, utilizing a paymaster is as simple as providing the paymaster RPC URL.
The Paymaster screen includes an RPC URL
selector for chain-specific URLs. All
URLs follow the same format, varying only by chain ID, so you can generate the
URL in your Dapp based on the active chain.
By default, all policies will be validated in succession until one returns true.
There is the option of passing policyId
in the optional to the RPC. This can
be sent by the dapp via the the context
field per ERC 7677.
However - please note that different paymasters may accept policyId
with a
different key or format. For Reown’s Paymaster, that key is policyId
.
The schema itself is a simple object representation of the following
Is some key from a user operation equivalent to (or some other comparison) some value?
This is defined in params
as such:
The flexibility here lies in the ability to chain different conditionals together. For example, you can check if the User Op targets a specific smart contract and a particular function within that contract’s ABI. Since these fields are encoded within a UserOp’s callData
, two different methods are needed to access this information:
callDataMethodEquals
: Verifies that the callData
targets a specific functioncallDataToEquals
: Verifies that the callData
targets a specific contractEssentially, we want to combine the following two conditions:
To do this, we need to zoom out and see how to set the params
:
The new field we introduced here is ands
. The way the schema is designed, Each params
object, can be
accompanied with an ands
OR an ors
field which is an array of more params that will require that they
either all pass as true, or only one of them is true, respectively.
A params
object can not have both an ors
and
an ands
simultaneously. However, its “children” (the params in an ands
or ors
) can have different conditionals than their parent.
For example, to make it so that the above policy also passes for methodBar
and methodBaz
, it can be amended as follows:
This essentially is a schema translation of
The UserOp should target smart contract 0xa123.. and either use the methods
methodFoo
ormethodBar
ormethodBaz
.
Note that at the top it used ands
and then used ors
for the children. This is fully legal within the schema.
However, the following is incorrect :
In this case, the ors
will be completely ignored. If both ors
and ands
are present, then the ands
will take precedence.
For the policy to actually know how to read the callData
it needs to know the smart contract’s ABI.
For this we introduce 2 new fields. policyStaticProps
and metadata
. Both are essentially free range key-value
dictionaries used to store information within the policy to be accessed later. The key thing to note is that
values within policyStaticProps
can be accessed from within metadata
. This becomes invaluable with policies
that have multiple conditionals like the one above.
Essentially here, contractAbi
is a variable that callDataMethodEquals
requires. To supplement its value, we use <contract1.abi>
.
What <contract1.abi>
means is essentially policyStaticProps.contract1.abi
. The <>
indicate that this value is coming from policyStaticProps
.
Note that the values within policyStaticProps
can be named anything. The only constraint is that contractAbi
is named the same within the metadata
as that is what callDataMethodEquals
will look for.
Extrapolating this to our running example above, the complete policy becomes:
The final bit to making a valid policy is adding metadata
to the root of your policy, to keep basic metadata like what chains to support, the startTime and endTime.
These only need to be manually set when communicating with the API.
By design, certain elements of the JSON policy are not editable in the UI. Those
being: startTime
, endTime
and chainIds
. This is because they are edited in
the previous UI panels.
Adding this to the above gives us a complete and working policy.
The following is the culmination of all the above steps to create a complete policy.
In English, what this policy is saying is
The policy starts on the 23rd of October 2024, does not expire and will support Ethereum, Polygon and Testnet. For a UserOp to pass this policy, it needs to be targeting smart contract
0xa123cd918...
and it has to be using One of the following methods from the contract:methodFoo
ormethodBar
ormethodBaz
.
policyType
The type of policy, currently only useroperation_payload_control
is available.
policyStaticProps
Key value pair used as data storage for the policy
params
Where the core logic of a policy lives
key
The key within the UserOp to target, currently only EntryPoint v.07 is supported, so the available fields are:
sender
nonce
callData
callGasLimit
verificationGasLimit
maxFeePerGas
maxPriorityFeePerGas
op
The operation to apply within the params. Currently available:
equals
: Exact 1:1 match with value
lessThanOrEquals
: Is the numeric value less than or equals value
callDataMethodEquals
: Within callData
, is the method
equal to a value
contractAbi
defined in metadata
callDataToEquals
: Within callData
, is the to
equal to a value
value
The value to be compared to. Can be a string, number or boolean.
ands
Array consisting of policies (with policyType
and policyStaticProps
omitted)
ors
Array consisting of policies (with policyType
and policyStaticProps
omitted)
metadata
Key value pair used as data storage for a single params
Special fields within metadata
. At the root of a policy, there needs to be a metadata
object defined.
It has to contain the following:
startTime
ISO datetime stamp of when to start policy
endTime
ISO datetime stamp of when to end policy
chains
Array of chain IDs to support. number[]
Paymaster feature is currently in a limited access phase and only available by invite. If you’re interested in access, please contact us.
Click on “Add Policy” and follow the steps within the policy creation screen.
If you select the free plan, you will have unlimited access to sponsoring on testnets. Currently, only Sepolia is supported.
With the Pay-as-you-go plan, you will be asked to enter credit card information. You will not be billed immediately.
Instead you will be charged based on usage, with Paymaster Credits. This is calculated using a simple formula:
Billing occurs monthly; however, if a threshold of 100 USD is reached, an immediate charge will occur, and the billing cycle will reset.
All supported chains are enabled by default, but you can deselect any chain to sponsor transactions only on specific chains.
Policy logic can be updated in one of two ways:
There are distinct advantages to this:
Once created, the policy will become active immediately if the start date has already passed, making it ready for use.
All that is required is to
Sponsor Smart Account Deployment
checkbox.Based on EIP 5792 and ERC 7677, utilizing a paymaster is as simple as providing the paymaster RPC URL.
The Paymaster screen includes an RPC URL
selector for chain-specific URLs. All
URLs follow the same format, varying only by chain ID, so you can generate the
URL in your Dapp based on the active chain.
By default, all policies will be validated in succession until one returns true.
There is the option of passing policyId
in the optional to the RPC. This can
be sent by the dapp via the the context
field per ERC 7677.
However - please note that different paymasters may accept policyId
with a
different key or format. For Reown’s Paymaster, that key is policyId
.
The schema itself is a simple object representation of the following
Is some key from a user operation equivalent to (or some other comparison) some value?
This is defined in params
as such:
The flexibility here lies in the ability to chain different conditionals together. For example, you can check if the User Op targets a specific smart contract and a particular function within that contract’s ABI. Since these fields are encoded within a UserOp’s callData
, two different methods are needed to access this information:
callDataMethodEquals
: Verifies that the callData
targets a specific functioncallDataToEquals
: Verifies that the callData
targets a specific contractEssentially, we want to combine the following two conditions:
To do this, we need to zoom out and see how to set the params
:
The new field we introduced here is ands
. The way the schema is designed, Each params
object, can be
accompanied with an ands
OR an ors
field which is an array of more params that will require that they
either all pass as true, or only one of them is true, respectively.
A params
object can not have both an ors
and
an ands
simultaneously. However, its “children” (the params in an ands
or ors
) can have different conditionals than their parent.
For example, to make it so that the above policy also passes for methodBar
and methodBaz
, it can be amended as follows:
This essentially is a schema translation of
The UserOp should target smart contract 0xa123.. and either use the methods
methodFoo
ormethodBar
ormethodBaz
.
Note that at the top it used ands
and then used ors
for the children. This is fully legal within the schema.
However, the following is incorrect :
In this case, the ors
will be completely ignored. If both ors
and ands
are present, then the ands
will take precedence.
For the policy to actually know how to read the callData
it needs to know the smart contract’s ABI.
For this we introduce 2 new fields. policyStaticProps
and metadata
. Both are essentially free range key-value
dictionaries used to store information within the policy to be accessed later. The key thing to note is that
values within policyStaticProps
can be accessed from within metadata
. This becomes invaluable with policies
that have multiple conditionals like the one above.
Essentially here, contractAbi
is a variable that callDataMethodEquals
requires. To supplement its value, we use <contract1.abi>
.
What <contract1.abi>
means is essentially policyStaticProps.contract1.abi
. The <>
indicate that this value is coming from policyStaticProps
.
Note that the values within policyStaticProps
can be named anything. The only constraint is that contractAbi
is named the same within the metadata
as that is what callDataMethodEquals
will look for.
Extrapolating this to our running example above, the complete policy becomes:
The final bit to making a valid policy is adding metadata
to the root of your policy, to keep basic metadata like what chains to support, the startTime and endTime.
These only need to be manually set when communicating with the API.
By design, certain elements of the JSON policy are not editable in the UI. Those
being: startTime
, endTime
and chainIds
. This is because they are edited in
the previous UI panels.
Adding this to the above gives us a complete and working policy.
The following is the culmination of all the above steps to create a complete policy.
In English, what this policy is saying is
The policy starts on the 23rd of October 2024, does not expire and will support Ethereum, Polygon and Testnet. For a UserOp to pass this policy, it needs to be targeting smart contract
0xa123cd918...
and it has to be using One of the following methods from the contract:methodFoo
ormethodBar
ormethodBaz
.
policyType
The type of policy, currently only useroperation_payload_control
is available.
policyStaticProps
Key value pair used as data storage for the policy
params
Where the core logic of a policy lives
key
The key within the UserOp to target, currently only EntryPoint v.07 is supported, so the available fields are:
sender
nonce
callData
callGasLimit
verificationGasLimit
maxFeePerGas
maxPriorityFeePerGas
op
The operation to apply within the params. Currently available:
equals
: Exact 1:1 match with value
lessThanOrEquals
: Is the numeric value less than or equals value
callDataMethodEquals
: Within callData
, is the method
equal to a value
contractAbi
defined in metadata
callDataToEquals
: Within callData
, is the to
equal to a value
value
The value to be compared to. Can be a string, number or boolean.
ands
Array consisting of policies (with policyType
and policyStaticProps
omitted)
ors
Array consisting of policies (with policyType
and policyStaticProps
omitted)
metadata
Key value pair used as data storage for a single params
Special fields within metadata
. At the root of a policy, there needs to be a metadata
object defined.
It has to contain the following:
startTime
ISO datetime stamp of when to start policy
endTime
ISO datetime stamp of when to end policy
chains
Array of chain IDs to support. number[]