Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erc7683 allocator #6

Open
wants to merge 23 commits into
base: SimpleAllocator
Choose a base branch
from
Open

Erc7683 allocator #6

wants to merge 23 commits into from

Conversation

vimageDE
Copy link
Collaborator

Pull Request

Description

Introducing the ERC7683Allocator contract, a fully decentralized on chain allocator that follows ERC7683 as an origin settler.
It is build on top of the SimpleAllocator contract and extends it to follow the IOriginSettler interface.
The contract allows users to distribute their order via an open event during the lock process. There are two ways to distribute the order:

  • The open function is only callable by the sponsor directly and it requires them to have previously registered the claim hash in the Compact
  • The openFor´ function can be called by anyone. The caller must provide a signature proving the users intents, together with the GaslessCrossChainOrder`. This function can also be called without providing a signature, if the user has previously registered a claim hash in the Compact.

The token allocation is following the SimpleAllocator design, where all the tokens of a specific ID get locked, no matter how big the amount of the claim is. This makes it easier and more efficient to manage the expiration dates.

A topic still in discussion is the resolveFor function. In the current ERC7683 interface, it does not support the signature as an input. This leads to a returned ResolvedCrossChainOrder struct which does not contain the signature. While this can still be used to simulate the outcome on the destination chain, actually using the returned data would mean a filler would lose their reward, since the signature is required to prove the users intents during the claim. While fillers typically would use the correct ResolvedCrossChainOrder struct that was emitted in the open event, it still seems problematic to include a function that potentially returns invalid data.

It also includes changes to the foundry.toml, which are required to successfully compile TheCompact contract which is used for testing.

How Has This Been Tested?

The contract is still in development and neither audited, nor has it been fully tested.

@vimageDE vimageDE requested a review from a team as a code owner February 28, 2025 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant