Context

Permissions Standard Pre-draft

Permissions Standard Pre-draft for AA Wallets ONLY

Abstract

In this document, we outline the full flow for a DApp to 1) request permissions from a wallet, and 2) construct and send UserOps without requiring an active wallet connection.

This is useful for the “automation” use case where the DApp can automatically send UserOps for users even when they are offline, such as in the case of subscriptions.

The challenge we are trying to address is the fact that different smart account implementations format their nonce, calldata, and signature differently. So how do we enable the DApp to construct UserOps in a way that’s agnostic to the smart account implementation?

Step 1: DApp requests permissions

The DApp sends eth_requestPermissions with two fields: signer and permissions:

• signer specifies the session key that the DApp will be using to sign UserOps
• permissions specifies the list pf permissions that the DApp is requesting

{
	signer: {
		type: "ECDSA",
		data: {
			pubKey: "0x...",
		},
	},
	permissions: [
		{
			type: 'erc20_spending_limit',
			data: {
				"erc20Address": "0x...",
				"limit": "some big int in hex",
			},
			required: "false",
		},
	],
}

Note: there’s a proposal that we can piggyback this request on top of a CAIP call.

Step 2: Wallet replies with permissionsContext

The wallet replies with:

• A list of permissions that are granted
• An address for a UserOpConstructor contract which the DApp will use to construct UserOps
• A permissionsContext which is an opaque bytes array for using with UserOpConstructor

{
	"grantedPolicies": {
		{
			type: 'erc20_spending_limit',
			data: {
				"erc20Address": "0x...",
				"limit": "some big int in hex",
			},
		},
	},
	
	"permissionsContext": "some bytes",
	
	"userOpConstructor": "address of the UserOpConstructor",
	
	// Only needed if the account hasn't been deployed yet.
	// The DApp will set this data as the "initCode" field of the UserOp.
	"initCode": "0x...",
}

Step 3: DApp requests nonce and calldata