search

CoopHive / alkahest-mocks

3 stars 0 forks source link

No Associating Schemas with IArbiter #3

Closed polus-arcticus closed 1 month ago

polus-arcticus commented 2 months ago

making IArbiter not have an associated schema, to allow arbiters to validate stuff like "who is this for?", which is generic across attestations with different schema

so this would be only IObligation and IComment (maybe there's a new IStatement they both inherit from) has function getSchemaAbi() public pure virtual returns (string memory) {}, and only IArbiter has function getDemandAbi() public pure virtual returns (string memory) {}

https://github.com/CoopHive/tokens-for-docker-alkahest/blob/b7a79093684fe31863228f16306a285bf9db0e25/src/IArbiter.sol#L7

move this to IStatement https://github.com/CoopHive/tokens-for-docker-alkahest/blob/b7a79093684fe31863228f16306a285bf9db0e25/src/IArbiter.sol#L31

@mlegls for https://github.com/CoopHive/tokens-for-docker-alkahest/blob/b7a79093684fe31863228f16306a285bf9db0e25/src/IArbiter.sol#L11 does this imply that _checkExtrinsic(Attestation memory statement, bytes32 whoIsThisForSchema) ?

mlegls commented 2 months ago

Decoupling checkStatement from the statement makers means checkIntrinsic should probably be split into a bunch of utility functions in a library. I noticed while implementing ERC20PaymentStatement that there will be cases when attestation revocation doesn't mean invalid in the context of a particular checkStatement implementation.

There can still be a utility function that does all of them, but the pieces checkExpired, checkRevoked... should be individually available