Motivation

• Right now, it only takes one bad transaction for a malicious/buggy DApp to drain a user’s wallet.
• Users have to manually approve every transaction to keep their wallets safe.

There are many session key implementations that address these problems, and some MPC providers support “transaction policies” as well. However, these are all non-standardized and therefore introduce tight coupling between DApps and the wallet provider.

Abstract

We define a standard that specifies how DApps can request “permissions” from wallets. “Permissions” are policies that specify what transactions or messages that a DApp is allowed to sign and send.

Modes

There are two possible modes when requesting permissions:

• DApp-signing: the DApp manages the key that is assigned with the permissions.
  • DApp-signing mode is useful for automation — the DApp can send transactions for users even when they are offline.
  • Part of the request will be a “public key” of the key that the DApp manages.
• Wallet-signing: the wallet manages the key that is assigned with the permissions
  • Wallet-signing mode is useful for skipping signing prompts and keeping the user safe. The wallet will use a different key than the master key to sign transactions/messages in this mode.

API

We define an additional ETH JSON RPC which can be invoked either through an RPC call or an EIP-1193 provider: eth_requestPermissions

Request:

{
	// if signer is specified, the mode is DApp-signing
	// if signer is not specified, the mode is wallet-signing
	signer: {
		type: "ECDSA",
		data: {
			pubKey: "0x...",
		},
	},
	policies: [
		{
			type: 'erc20_spending_limit',
			data: {
				"erc20Address": "0x1234",
				"limit": "some big int in hex",
			},
			required: "false",
			
			// start_date and end_date are both optional
			// These are UNIX timestamps
			start_date: 1710467083,
			end_date: 1710567083,
		},
	],
}

Response:

{
	"grantedPolicies": {
		{
			type: 'erc20_spending_limit',
			data: {
				"erc20Address": "0x1234",
				// note that this value could be different than in the request
				// if the user had decided to grant a lower spending limit.
				"limit": "some big int in hex",
				start_date: 1710467083,
			  end_date: 1710567083,
			},
		},
	},
}

Standard Policy Types

• Spending limits:
  • erc20_spending_limit
  • fiat_spending_limit
  • eth_spending_limit
• Gas limits:
  • eth_gas_limit
  • erc20_gas_limit (presumably the wallet would use a ERC20 paymaster).
  • paymaster_required (if true, the DApp must use a paymaster)