Version 0 Review PR #29
Conversation
| using SafeTransferLib for address; | ||
|
|
||
| // Storage slot seed for ERC6909 state, used in computing balance slots. | ||
| uint256 private constant _ERC6909_MASTER_SLOT_SEED = 0xedcaa89a82293940; |
There was a problem hiding this comment.
what is this value? where did it come from?
There was a problem hiding this comment.
this is from solady's ERC6909 implementation, since the _release and _withdraw functions use the same general pathways as the standard transfers (but skip allowance checks and transfer hooks)
| * @param fnIn Function pointer to `ClaimProcessorLib.processSimpleClaim`. | ||
| * @return fnOut Modified function used in `ClaimProcessorLogic._processBasicClaim`. | ||
| */ | ||
| function usingBasicClaim(function(bytes32, uint256, uint256, bytes32, bytes32, function(address, address, uint256, uint256) internal returns (bool)) internal returns (bool) fnIn) |
There was a problem hiding this comment.
Can you explain at a high level why this is necessary? I've read the natspec but still not sure. Which one is the correct function type for the function thats going to be called? Why would the type ever be incorrect and need changing?
There was a problem hiding this comment.
Yeah, using this function as an example:
ClaimProcessorLibhas a functionprocessSimpleClaimthat is used as a shared entrypoint for processing four different claim types (basic claim, claim with witness, multichain claim, and multichain claim with witness) where the only key differences are how the claim hash is derived and what the calldata offset to the relevant data is. To facilitate this, theprocessSimpleClaimfunction takes auint256 calldataPointerargument instead of like aBasicClaimcalldata argument.- When we're actually calling
processSimpleClaiminside ofClaimProcessorLogic._processBasicClaim, theclaimPayloadhas aBasicClaim calldata claimPayloadtype. While you could do a typecast to a uint256 inside of that function before callingprocessSimpleClaim, it uses extra gas and critically takes up more contract size, so instead we can use a function cast as a "zero-cost abstraction" to accomplish the same thing - The
fnInfunction matches the arguments thatprocessSimpleClaimexpects, but thefnOutfunction matches the argument types that are actually being provided
| // Message signed by the sponsor that specifies the conditions under which their | ||
| // tokens can be claimed; the specified arbiter verifies that those conditions | ||
| // have been met and specifies a set of beneficiaries that will receive up to the | ||
| // specified amount of tokens. | ||
| struct Compact { | ||
| address arbiter; // The account tasked with verifying and submitting the claim. | ||
| address sponsor; // The account to source the tokens from. | ||
| uint256 nonce; // A parameter to enforce replay protection, scoped to allocator. | ||
| uint256 expires; // The time at which the claim expires. | ||
| uint256 id; // The token ID of the ERC6909 token to allocate. | ||
| uint256 amount; // The amount of ERC6909 tokens to allocate. | ||
| // Optional witness may follow. | ||
| } |
There was a problem hiding this comment.
do you expect that the "conditions under which their tokens can be claimed" to be encapsulated in optional witness data or in the address of the arbiter?
There was a problem hiding this comment.
I think generally the conditions would be specified in the witness data which is in turn leveraged by the arbiter; that way the arbiter can be more general-purpose!
This PR is meant to serve as a hub for review comments on Version 0.