Add EIP-5805: Voting with delegation #5805

Amxx · 2022-10-20T10:30:00Z

No description provided.

eth-bot · 2022-10-20T10:30:53Z

All tests passed; auto-merging...

(pass) eip-5805.md

classification
`updateEIP`

passed!

EIPS/eip-5805.md

Co-authored-by: Pandapip1 <[email protected]>

Pandapip1

There's some formatting stuff that could be improved, but this is fine for a draft.

xinbenlv

Hi @Amxx , glad to see this EIP. I think it's a super important area to address.

Left some comments of the first round.

xinbenlv · 2022-10-27T03:51:40Z

EIPS/eip-5805.md

+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-07-04


Shall this be update to 2022-10-19 to reflect its start time?

I started writing the draft of this document in july ... but waited until post-devcon to create the PR. I'm not sure what "created" is supposed to represent. I'd don't really care. If you editor thing 2022-10-19 is a better date, then I'm ok with that

Sure. I think the nature of this is more of use the date for time it first get drafted, I don't have a preference either. Leaving it for @Pandapip1 and @SamWilsn who have more authoritative answer

EIPS/eip-5805.md

xinbenlv · 2022-10-27T03:54:31Z

EIPS/eip-5805.md

+  inputs:
+    - name: account
+      type: address
+    - name: timepoint


The timepoint parameter should match the operating mode of the contract.

The wording is not entire clear to me. Does it require timepoint to be consistent with now()?

It needs to be consistent in the sens that:

if now() returns a block.number (or if now() does not exist), then timepoint should be a block number.

if now() returns a timestamp, then timepoint should be a timestamp.

EIPS/eip-5805.md

xinbenlv · 2022-10-27T04:28:20Z

EIPS/eip-5805.md

+### Solidity interface
+
+```sol
+interface IERC_XXXX {


[Optional] Do you want to consider adding EIP-165 identifer?

I'm not sure, that is a good point.

I love EIP-165 but the truth is I don't see it used that often in the field.

also, with "now()" being optional, I'm not sure what the identifier should be?

but the truth is I don't see it used that often in the field.

Strongly agreed with you. I am working on a proposal providing a competing identifier of EIP-165 https://eips.ethereum.org/EIPS/eip-5269 to rethink how we could make identifier useful. Happy to chat and get valueable input from you, If you @Amxx, being the main author of openzeppelin, also think that EIP-165 has been restricted of adoption, that speaks a lot.

That said, if you are not sure, maybe consider putting that into the Rationale section if you choose to or not to add EIP-165 because it's quite

also, with "now()" being optional, I'm not sure what the identifier should be?

Good point. It also makes restriction usage of EIP-165. I think the common approach is to make EIP-165 out of all required field, and then any optional one will have an IERC5805Extension kind of thing which has its own EIP-165 identifier.

xinbenlv · 2022-10-27T04:32:40Z

EIPS/eip-5805.md

+
+When a "delegator" delegates its tokens voting power to a "delegatee", its balance is added to the voting power of the delegatee. If the delegator changes its delegation, the voting power is subtracted from the old delegatee's voting power and added to the new delegate's voting power. The voting power of each account is tracked through time so that it is possible to query its value in the past. With tokens being delegated to at most one delegate at a given point in time, double voting is prevented.
+
+Whenever tokens are transferred from one account to another, the associated voting power should be deducted from the sender's delegate and added to the receiver's delegate.


I wonder if you want to specify whether this is SHOULD or "MUST" for handling the transfer behavior

In this EIP, the notion of "voting power" is purposefully open to interpretation. The most obvious case is to use the balances, but I think it is important to not be to restrictive and allow for other approaches.

In particular, I want this EIP to support quadratic voting. This means that, when an account transfers tokens to another, the new voting power of delegate might actually not change because of quadratic effects.

That's totally reasonable. If it's purposefully open to interpretation, I'd suggest

change the "should" to "MAY"

articulate it's purposefully open to interpretation / implementation choice in the Rationale section

I'll stay with SHOULD .. because that what you should do unless you have a good reason not to, and not what you may do and you are not sure.

I'll add something in the Rationale section

Sounds good

Amxx · 2022-10-31T11:03:02Z

We might need to rename the now() function, because of name conflicts with solidity's now keyword (deprecated since 0.7.0 but still raising issues).

Should we go for clock() ?

frangio · 2022-11-04T16:58:26Z

clock sounds good to me. Another alternative could be tick.

xinbenlv · 2022-11-04T17:24:11Z

clock sounds good to me. Another alternative could be tick.

Is it the intention of the function now() to represent the current point of time in either timestamp or blocknum?

I feel the tick or clock will all strongly imply timestamp and could cause trouble if contract developers choose to implement blocknum but client interpreting it as timestamp.

I'd brainstorm something like currentPointOfTime(), well that's a bit unfortunately long, please help find better name

xinbenlv · 2022-11-04T17:57:56Z

Also, realizing snapshot doesn't work at blocknum level. I am proposing #5875 to retrieve TX Num. Wondering if for better security, we should support TX level of voting weight snapshot

github-actions · 2022-12-19T00:16:26Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

Amxx · 2023-01-05T15:09:39Z

There is still ongoing discution about this EIP (which IMO should happen on the ethereum magician thread, and not here) ... but I believe the proposal state is sufficient to merge as a draft.

If there is anything preventing that from being merged (as a draft), please let me know what needs to be fixed.

Pandapip1 · 2023-01-06T18:39:28Z

The only rule about the creation date is it can't be in the future.

initial draft

13a599e

github-actions bot added c-new Creates a brand new proposal e-number Waiting on EIP Number assignment t-erc labels Oct 20, 2022

add eip number

4c9b863

github-actions bot removed the e-number Waiting on EIP Number assignment label Oct 20, 2022

Amxx added 3 commits October 20, 2022 12:31

rename focument

ede206e

add discussion

84f28f2

fix EIP Walidator checks

3daaf38

github-actions bot added the s-draft This EIP is a Draft label Oct 20, 2022

Amxx marked this pull request as ready for review October 20, 2022 14:28

Amxx requested a review from eth-bot as a code owner October 20, 2022 14:28

Pandapip1 changed the title ~~Voting with delegation~~ Add EIP-5805: Voting with delegation Oct 23, 2022

Pandapip1 suggested changes Oct 23, 2022

View reviewed changes

EIPS/eip-5805.md Outdated Show resolved Hide resolved

EIPS/eip-5805.md Outdated Show resolved Hide resolved

Amxx dismissed a stale review via 2670277 October 24, 2022 11:56

Amxx and others added 2 commits October 24, 2022 13:56

Apply suggestions from code review

2670277

Co-authored-by: Pandapip1 <[email protected]>

fix typo

28be477

Pandapip1 previously approved these changes Oct 25, 2022

View reviewed changes

xinbenlv reviewed Oct 27, 2022

View reviewed changes

Amxx mentioned this pull request Oct 27, 2022

block.timestamp compatible Checkpoints OpenZeppelin/openzeppelin-contracts#3784

Closed

poojaranjan mentioned this pull request Nov 1, 2022

EIP Editing Office Hour Meeting 5 ethcatherders/EIPIP#186

Closed

xinbenlv mentioned this pull request Nov 11, 2022

Add EIP-5920: PAY opcode #5920

Merged

poojaranjan mentioned this pull request Nov 15, 2022

EIP Editing Office Hour Meeting 6 ethcatherders/EIPIP#188

Closed

github-actions bot added the w-stale Waiting on activity label Dec 19, 2022

rename now → clock

937a4ed

Amxx dismissed Pandapip1’s stale review via 937a4ed January 5, 2023 15:07

Merge remote-tracking branch 'origin/master' into vote_with_delegation

fde2d11

fix markdown linter

250c842

Amxx requested a review from Pandapip1 January 6, 2023 10:58

Pandapip1 approved these changes Jan 6, 2023

View reviewed changes

Pandapip1 closed this Jan 6, 2023

Pandapip1 reopened this Jan 6, 2023

eth-bot enabled auto-merge (squash) January 6, 2023 18:40

eth-bot approved these changes Jan 6, 2023

View reviewed changes

eth-bot merged commit 56c5187 into ethereum:master Jan 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP-5805: Voting with delegation #5805

Add EIP-5805: Voting with delegation #5805

Amxx commented Oct 20, 2022

eth-bot commented Oct 20, 2022 •

edited

Loading

Pandapip1 left a comment

xinbenlv left a comment

xinbenlv Oct 27, 2022

Amxx Oct 27, 2022

xinbenlv Oct 27, 2022

xinbenlv Oct 27, 2022

Amxx Oct 27, 2022

xinbenlv Oct 27, 2022

Amxx Oct 27, 2022

Amxx Oct 27, 2022

xinbenlv Oct 27, 2022 •

edited

Loading

xinbenlv Oct 27, 2022

xinbenlv Oct 27, 2022

Amxx Oct 27, 2022

xinbenlv Oct 27, 2022

Amxx Oct 28, 2022

xinbenlv Oct 28, 2022

Amxx commented Oct 31, 2022

frangio commented Nov 4, 2022 •

edited

Loading

xinbenlv commented Nov 4, 2022

xinbenlv commented Nov 4, 2022

github-actions bot commented Dec 19, 2022

Amxx commented Jan 5, 2023

Pandapip1 commented Jan 6, 2023


		When a "delegator" delegates its tokens voting power to a "delegatee", its balance is added to the voting power of the delegatee. If the delegator changes its delegation, the voting power is subtracted from the old delegatee's voting power and added to the new delegate's voting power. The voting power of each account is tracked through time so that it is possible to query its value in the past. With tokens being delegated to at most one delegate at a given point in time, double voting is prevented.

		Whenever tokens are transferred from one account to another, the associated voting power should be deducted from the sender's delegate and added to the receiver's delegate.

Add EIP-5805: Voting with delegation #5805

Add EIP-5805: Voting with delegation #5805

Conversation

Amxx commented Oct 20, 2022

eth-bot commented Oct 20, 2022 • edited Loading

All tests passed; auto-merging...

(pass) eip-5805.md

Pandapip1 left a comment

Choose a reason for hiding this comment

xinbenlv left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xinbenlv Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Amxx commented Oct 31, 2022

frangio commented Nov 4, 2022 • edited Loading

xinbenlv commented Nov 4, 2022

xinbenlv commented Nov 4, 2022

github-actions bot commented Dec 19, 2022

Amxx commented Jan 5, 2023

Pandapip1 commented Jan 6, 2023

eth-bot commented Oct 20, 2022 •

edited

Loading

xinbenlv Oct 27, 2022 •

edited

Loading

frangio commented Nov 4, 2022 •

edited

Loading