enhancement: Attestation signatures #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
msg.sender attestations
The registry now supports native attestations and revocations. Instead of only allowing for signed (EOA/
ERC-1271) attestations, they can now be issued via normal transaction. the attestation will be assigned tomsg.sendersupport for non v,r,s signatures
registry now supports attestations / revocations that use arbitrary bytes signatures for
ERC-1271.This allow multisigs accounts like safe to sign attestations/revocations with multiple signatures that would not fit into
uint8 v, bytes32 r, bytes32 s. Further more, this would allowERC-1271endpoints to validate other signature patters likeBLSsignatures, or custom validation logic.This feature addresses Issue: #15