Special thanks to Diego for reading over an early version of this post

One of the issues that people are noticing with PWAs that support Privy and other wallet-as-a-service providers is that this process creates a lot of fragmentation for data and value.

If I have a boatload of Blackbird points, 2 ETH worth of keys on my Friendtech, etc – it becomes really difficult to aggregate this value.

One simple solution is that we can just use a shared wallet across all these platforms – which is the approach Rainbow is choosing.

However, this comes with the tradeoff that the shared wallet needs user approval for every interaction – at best adding friction and at worst making high interaction apps like games impossible to use.

Smart Contract Wallets?

One of the potential solutions is to bring smart contract wallets into the mix in conjunction with these existing solutions – after all, with these wallets, we can introduce a session key like UX or enforce logic around transaction validation (see Safe’s Zodiac Guards). There’s even work being done by the Alchemy team to allow for hooks in ERC 6900, which can provide interesting depth to the validation parameters.

One of the key issues is that as we take more time to create onchain validation logic, the more complexity gets tacked on. If I sign a message that transfers my Opensea position, or I rebalance my transactions in a certain way – it’s easy to slip this by the validation logic.

As it turns out, it’s really difficult to try to recreate the flexibility that an EOA has in an onchain setting.

There’s no greater example of this complexity than ERC-4337, which is focused on allowing ‘gasless’ transactions.

One of the key issues that 4337 runs into is the need to add transactions without the originating address spending any ETH to execute it – usually because the address isn’t prefunded. This involved an alternate mempool, bundlers, and onchain validation to ensure that this can work.

This is hacky at best, and becomes a material setback to the developer experience at worst. It’s not uncommon for buidlers to skip working with AA and just use a Privy for instance as well – which has all the drawbacks mentioned before.

Here are two ideas that I explored with my recent ethOnline hack - pmnts, a PWA that’s focused on mobile payments.

• centralized delegated signing

One simple solution is to enable native centralized delegated signing – if the account doesn’t have any ETH to pay for transactions, the app developer can execute transactions with their own backend.

Crucially, if the user wants out of this more seamless UX, they can fund their wallet with ETH and use the established flow to fund their own transactions.

This is huge as it skips the complexity of needing to sign transactions while enabling sovereignty if the user chooses so.

This is actually a pattern pioneered by the Lens team under the name of dispatched transactions, which allows users to delegate signing ability to the app they are using (e.g. Lenster).

• Approval based funding

This is an idea borrowed from Fintech.

When I use Venmo, I’m not bounded by the amount of money I have in Venmo already – I can use funds linked to any bank accounts I’ve linked to my Venmo account. Similarly, when I receive a payment, I can flush these funds back to my bank account.

This kind of UX could be really powerful and simple to bring in with adoption. By using Permit2 for signed token approvals, apps can spend down on user permits as they mint NFTs or spend their assets within the app.

This is something the Rainbow Wallet Extension is exploring as well – but an approval to a user’s Coinbase account can make this whole flow even easier, directly pulling from fiat to crypto without the user even needing to make an explicit interaction or even needing Metamask.

Again, this is something Lens has explored with Allow/Revoking modules, but the focus on Lens specific integrations makes this more difficult to generalize.

Conclusion

4337 is here to stay, there’s a significant amount of momentum around this ERC, and I do think that parity with EoAs is ultimately a good thing – especially in a world where EoAs get slowly get phased out in favor of AA.

One of the key issues with 4337 however, is that it forces people to think very specific ways about transactions – there needs to be an external bundler, there needs to be an app specific mempool, etc. However, especially as we get a better idea of what our apps need and crucially need not to do (e.g. sign arbitrary calldata for an arbitrary contract) – we can get a better idea of what we truly need.

Crucially, I think there are good ideas that we can pull in from fintech and even Web2 to make web3 experiences more robust – and hopefully this gives some good ideas in this direction.

Special thanks to Diego for reading over an early version of this post

One of the issues that people are noticing with PWAs that support Privy and other wallet-as-a-service providers is that this process creates a lot of fragmentation for data and value.

If I have a boatload of Blackbird points, 2 ETH worth of keys on my Friendtech, etc – it becomes really difficult to aggregate this value.

One simple solution is that we can just use a shared wallet across all these platforms – which is the approach Rainbow is choosing.

However, this comes with the tradeoff that the shared wallet needs user approval for every interaction – at best adding friction and at worst making high interaction apps like games impossible to use.

Smart Contract Wallets?

One of the potential solutions is to bring smart contract wallets into the mix in conjunction with these existing solutions – after all, with these wallets, we can introduce a session key like UX or enforce logic around transaction validation (see Safe’s Zodiac Guards). There’s even work being done by the Alchemy team to allow for hooks in ERC 6900, which can provide interesting depth to the validation parameters.

One of the key issues is that as we take more time to create onchain validation logic, the more complexity gets tacked on. If I sign a message that transfers my Opensea position, or I rebalance my transactions in a certain way – it’s easy to slip this by the validation logic.

As it turns out, it’s really difficult to try to recreate the flexibility that an EOA has in an onchain setting.

There’s no greater example of this complexity than ERC-4337, which is focused on allowing ‘gasless’ transactions.

One of the key issues that 4337 runs into is the need to add transactions without the originating address spending any ETH to execute it – usually because the address isn’t prefunded. This involved an alternate mempool, bundlers, and onchain validation to ensure that this can work.

This is hacky at best, and becomes a material setback to the developer experience at worst. It’s not uncommon for buidlers to skip working with AA and just use a Privy for instance as well – which has all the drawbacks mentioned before.

Here are two ideas that I explored with my recent ethOnline hack - pmnts, a PWA that’s focused on mobile payments.

• centralized delegated signing

One simple solution is to enable native centralized delegated signing – if the account doesn’t have any ETH to pay for transactions, the app developer can execute transactions with their own backend.

Crucially, if the user wants out of this more seamless UX, they can fund their wallet with ETH and use the established flow to fund their own transactions.

This is huge as it skips the complexity of needing to sign transactions while enabling sovereignty if the user chooses so.

This is actually a pattern pioneered by the Lens team under the name of dispatched transactions, which allows users to delegate signing ability to the app they are using (e.g. Lenster).

• Approval based funding

This is an idea borrowed from Fintech.

When I use Venmo, I’m not bounded by the amount of money I have in Venmo already – I can use funds linked to any bank accounts I’ve linked to my Venmo account. Similarly, when I receive a payment, I can flush these funds back to my bank account.

This kind of UX could be really powerful and simple to bring in with adoption. By using Permit2 for signed token approvals, apps can spend down on user permits as they mint NFTs or spend their assets within the app.

This is something the Rainbow Wallet Extension is exploring as well – but an approval to a user’s Coinbase account can make this whole flow even easier, directly pulling from fiat to crypto without the user even needing to make an explicit interaction or even needing Metamask.

Again, this is something Lens has explored with Allow/Revoking modules, but the focus on Lens specific integrations makes this more difficult to generalize.

Conclusion

4337 is here to stay, there’s a significant amount of momentum around this ERC, and I do think that parity with EoAs is ultimately a good thing – especially in a world where EoAs get slowly get phased out in favor of AA.

One of the key issues with 4337 however, is that it forces people to think very specific ways about transactions – there needs to be an external bundler, there needs to be an app specific mempool, etc. However, especially as we get a better idea of what our apps need and crucially need not to do (e.g. sign arbitrary calldata for an arbitrary contract) – we can get a better idea of what we truly need.

Crucially, I think there are good ideas that we can pull in from fintech and even Web2 to make web3 experiences more robust – and hopefully this gives some good ideas in this direction.