-
Notifications
You must be signed in to change notification settings - Fork 1
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 #4
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be helpful for review if you broke out this PR into smaller chunks. There's a lot to go through here.. I could see it even being
1 - docs/foundry settings/workflow changes
2 - interfaces/ the set up for the code changes
3 - major code changes + tests
Also looks like CI is failing on build? Worth digging into so we can get the tests to run in CI
3f25e0e
to
aeefd91
Compare
83b0038
to
8db0d7b
Compare
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:open
function is only callable by the sponsor directly and it requires them to have previously registered the claim hash in the CompactopenFor´ 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 returnedResolvedCrossChainOrder
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 correctResolvedCrossChainOrder
struct that was emitted in theopen
event, it still seems problematic to include a function that potentially returns invalid data.How Has This Been Tested?
The contract is still in development and neither audited, nor has it been fully tested.