Batching (accountCreation +) addOwnerAddress(spendPermissions) + approve(user, protocol, ....) + (more...)

[evmKnows]

Hi there,

first and foremost thank you for fleshing out an AA native "Permit2"

Would be particularly interested if the AA / Spend-Permission architecture would allow a batch / zap style onboarding to AA + SpendPermissions contract + dApp,

and if it is generally recommended to compress user actions all-in-one (balance between convenient UX vs. establishing expectations of "signing long jsons" > users being overloaded with TypedData > reading them less > potentially getting rekt in the future)

would love to hear your thoughts.

Vaguely fleshed out snippet below:

        CoinbaseSmartWallet.Call[] memory calls = new CoinbaseSmartWallet.Call[](3);
        calls[0].target = address(account);
        calls[0].value = 0;
        calls[0].data = abi.encodeWithSignature("createAccount(bytes[],uint256)", allInitialOwners, 0);
        calls[1].target = address(account);
        calls[1].value = 0;
        calls[1].data = abi.encodeWithSignature("addOwnerAddress(address)", address(spendPermissions));
        calls[2].target = address(spendPermissions);
        calls[2].value = 0;
    	calls[2].data = abi.encodeWithSignature(
    		"approve((address,address,address,uint160,uint48,uint48,uint48,uint256,bytes))",
    		.....
		);
		.... perform more calls
		
        bytes memory prepareData = abi.encodeWithSignature("executeBatch((address,uint256,bytes)[])", calls);

[ilikesymmetry]

Sorry for the long delay with a response, and thanks for taking the time to ping us!

Batching approve calls within a batch doing other operations is definitely a goal of Spend Permissions. To clarify from your sample code, the approve would not apply to the new account created in calls[0] though because approve relies on msg.sender == permission.account.

One example we're entertaining for example is creating a "sub-account" and giving it a Spend Permission over a "main account" to withdraw assets. For example, spawning an investing account that can continually withdraw from savings to allocate into different investments. Does this example match your intention with the code snippet?

[evmKnows]

Sorry for the long delay with a response, and thanks for taking the time to ping us!

Batching approve calls within a batch doing other operations is definitely a goal of Spend Permissions. To clarify from your sample code, the approve would not apply to the new account created in calls[0] though because approve relies on msg.sender == permission.account.

One example we're entertaining for example is creating a "sub-account" and giving it a Spend Permission over a "main account" to withdraw assets. For example, spawning an investing account that can continually withdraw from savings to allocate into different investments. Does this example match your intention with the code snippet?

I see I see, thought it might work if calldata is executed sequentially that by the time it reaches the approve, its good to go.

We are working on consumer, targeting non-Web3 natives as well, so the intention is to see what the limits are wrt getting users onboard with Smart Accounts.

We desperately want to avoid Web2 flows with centralized SSOs controlling SCAs, its imo a very bad pattern that might lessen the perceived security assumptions of wallets by newer entrants. It should always be a passkey at the very least. At the same time I suspect newer entrants might have trouble performing multiple operations (understanding what it all is in the first place)

Just to paint a picture of an ideal flow:

• User is new to crypto > trigger SCA creation with Batch (counterfactual)
• Fiat on-ramp flow to counterfactual SCA address
• Callback from on-ramp > trigger actual SCA creation & execute batch (sponsored)

Whereby the Batch is comprised of:

• Swapping ETH/USDC to TOKEN
• Depositing into a payments escrow / dApp
• Approving for future gasless deposits to escrow
• Logging in

The above flow is currently working 1-sig gasless (Token/ETH to Token + rest of the batch), but only for EOAs, or existing SCAs