On chain allocator

[mgretzke]

Pull Request

Description

Adding the OnChainAllocator and the ERC7683Allocator.

OnChainAllocator

• A new, fully on chain allocator, allowing to create allocations fully trustless.
• A user can do an allocation for themselves.
• An on chain allocation on behalf of someone else either requires a previously registered order on the compact, or a signature verifying the users intents.
• A user can has multiple active allocations of the same token ID at the same time, as long as he has sufficient balance of that token on the compact.
• It is also possible to do an allocation + deposit + registration on the compact. This is possible to do on behalf of anyone, as long as the msg.sender provides the tokens subject to the registered order.
• Uses BatchCompacts by default. Single Compacts must be provided in the batch format.

ERC7683Allocation

• An ERC7683 conform version of the OnChainAllocator.

Not all contracts are fully tested yet.

[marktoda]

first pass thoughts

[marktoda]

unclear to me why we do this multiplication - could use better explanation I think

[marktoda]

could this be internalized into _toNonceId?

[marktoda]

should deposit be depositId instead? just deposit makes me think its an amount

[mgretzke]

I will create a better documentation for it!

deposit is actually a boolean in the Order struct, so it can always be either 0 or 1. I just use it as a uint32, because it is stored in the same calldata slot as the expires in the OrderDataOnChain:

    struct OrderDataOnChain {
        Order order; // The remaining BatchCompact and Mandate data
        uint256 expires; // COMPACT - The time at which the claim expires and the user is able to withdraw their funds.
    }

    struct OrderDataGasless {
        Order order; // The remaining BatchCompact and Mandate data
        bool deposit; // Weather the order includes a deposit of the relevant tokens. This allows to skip a sponsor confirmation
    }

Thats why it is returned as "additionalData" from the _decodeOrderData function, since it is different depending on if the open or openFor function is called. Which is nice in this case, because it allows us to use it for calculations.

Basically, if you allocateAndRegister for someone else (so deposit == 1), you will then receive an individual nonce, completely independent of the sponsors incrementing nonces. This is to prevent griefing. Imagine a user creates a signature for a specific nonce, and a relayer will do the allocation for him. If allocateAndRegister was using the same incrementing nonces of the user, someone could essentially "burn" a valid signature by incrementing the nonce via a deposit (allocateAndRegister) of some worthless token on the users behalf.

If I would always scope the nonce to the caller though, the users signature would always be scoped to a specific relayer and worthless to any other relayer (except if they happen to currently be at the exact same nonce).
Thats why I multiply by deposit. If it is doing a allocateAndRegister call (deposit == 1), the callers signature will become part of the nonce scope (msg.sender * 1). If the caller is doing an allocateFor call (deposit == 0), their address will get wiped to address zero and the nonce will be in the scope of the user. This way, the system fully support incrementing nonces which is way cheaper (updating a storage slot instead of writing to a clean one each allocation) and easier, because the contract just assigns an incoming allocation a nonce, which means a user does not have to know do any nonce management beforehand.

[marktoda]

comment could be more clear I think - ie why? maybe like "branchless: if not deposit => 0, else qualification * deposit" or something