update allo to support account abstraction on Allo.sol

[thelostone-mc]

Octant had expressed interest in using Allo but would do so only if we support https://www.erc4337.io/ The goal here is identity what changes would we need to make to ensure Allo is compliant with 4337

[0xAustrian]

In the ERC4337 standard tx are sent by a bundler to a entrypoint, with the signature of the owner of the SC Wallet, an example flow would look like:

owner (EOA)→bundler (EOA)→ entrypoint (contract) → SC Wallet (contract) → Allo (contract)

Suppose that we have a function inside Allo.sol with the following code:

function exec() external {
    senderToOrigin[msg.sender] = tx.origin;
}

When calling exec() directly from an EOA msg.sender and tx.origin will be the same value (the address of the EOA) but when calling from a SC Wallet that uses the ERC4337 standard msg.sender will be the SC Wallet and tx.origin will be the bundler.

This same principle applies when using a Safe.

If the functions has some modifier restricting the calling like onlyPoolAdmin, the account registered as admin should be the SC Wallet NOT the owner of it.

Changes needed:

• Remove usage of tx.origin. Only 1 case is found: here

[thelostone-mc]

Sharing some context. The tx.origin exists because batchAllocate wasn't supported for NATIVE tokens and we had to use an external contract https://github.com/gitcoinco/allo-multi-round-checkout/blob/main/contracts/MultiRoundCheckout.sol to do the same and it was essential to identify how to identify unique contributions at the indexer level

Given that batchAllocate supports Native, we can ditch using the MultiRoundCheckout in favour of batchAllocate

Follow up question: would we need to add any sortof function dedicated to support SCW. I don't think we'd need but just checking

[0xAustrian]

Follow up question: would we need to add any sortof function dedicated to support SCW. I don't think we'd need but just checking

No extra functions afaik.