You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Support ERC20Votes delegation as a built-in operation type.
Describe the solution you'd like
The interface can be similar to ERC20_TRANSFER operations. When a user queries the /construction/preprocess endpoint for token delegation, they'll need to provide operations with the following schema:
A new operation type, ERC20VOTERS_DELEGATE, is introduced to describe the intent of an ERC20Votes delegate call.
There must be exactly two operations for an ERC20Votes delegate call; the first representing an account that's delegating votes, and the second represents the account that's being delegated votes to.
The type of each operation must be set to ERC20VOTES_DELEGATE.
The value of each operation must be set to zero.
The currency must contain a valid contractAddress in its metadata.
The contractAddress should point to an ERC20Votes compatible token.
Once the metadata is created, it can be forwarded through the usual flow to construct, sign and submit the tx.
Describe alternatives you've considered
Additional context
The outlined schema is based off of the design used in optimism-rosetta.
The text was updated successfully, but these errors were encountered:
The receipt of such transactions contain DelegateChanged events. There's already logic in roseta-geth-sdk to parse ERC20 transfer events. Parsing delegate calls would be similar.
Is your feature request related to a problem? Please describe.
Support ERC20Votes delegation as a built-in operation type.
Describe the solution you'd like
The interface can be similar to
ERC20_TRANSFER
operations. When a user queries the/construction/preprocess
endpoint for token delegation, they'll need to provide operations with the following schema:ERC20VOTERS_DELEGATE
, is introduced to describe the intent of an ERC20Votes delegate call.ERC20VOTES_DELEGATE
.contractAddress
in its metadata.The
contractAddress
should point to an ERC20Votes compatible token.Once the metadata is created, it can be forwarded through the usual flow to construct, sign and submit the tx.
Describe alternatives you've considered
Additional context
The outlined schema is based off of the design used in optimism-rosetta.
The text was updated successfully, but these errors were encountered: