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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Permissioned Across-v2 bond token #226
feat: Permissioned Across-v2 bond token #226
Changes from 1 commit
3609106
91c1780
50c957d
551f8d8
2dfd014
992a479
4213b70
fc4e98e
6830850
be0b346
edbee53
5215b60
b1096e8
d860e61
2ae7164
a6bad25
571b883
104ec28
b6a2598
ee0aedb
f4de94c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer sticking to existing naming convention and not prefixing this with a _. Maybe name HubPoolExtendedInterface or something, or even IHubPool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point - I'll find something better 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented: 91c1780
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure V2 is necessary. Do you think we should name it Proposer Bond instead of just Bond?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preface: Naming things is hard :)
My thinking with the "v2" naming is that this token has a finite lifespan - it will only be in use as long as the current (Across v2) HubPool is deployed (nb. the HubPool address is immutable, per current implementation). That's why I preferred to include v2 in the name.
I'd prefer not to include "Proposer" in the name, since this token is also needed to dispute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally don't like Versions in token names, look at UMA Voting Token V1 for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"v2" removed: ee0aedb
I do think it's a different scenario to UMA v1, but I can live with either :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can we come up with a catchier symbol? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"AMT" => "Across Moon Token" ?
(Slightly) more seriously:
APRT => Across Proposer Responsibility Token
APPT => Across Permissioned Proposer Token
APDT => Across Permisionless Dispute Token
AHST => Across HubPool Security Token
IDK 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will think on this more haha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean proposer's can't dispute themselves? I don't think we should block such behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check only requires that one of the conditions is true, so approved proposers can always self-dispute without impediment (and, all other users can dispute as well). There's a test that verifies that - see test/BondToken.e2e.ts line 72.
The statement
hubPool.rootBundleProposal().proposer != src
does seem counter-intuitive at first. It's there based on the observation that when a non-approved proposer is attempting to propose, their address is recorded as rootBundleProposal.proposer.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is extremely counterintuitive, but it's really clever. This is the sort of logic that I think Certora would be really good for verifying. We would probably want to verify that any address with tokens can always send a dispute.
I'm not super worried about this edge case, but this logic does seem to mean that if I proposed and then I was removed from the whitelist, I would then be no longer able to dispute myself.
Just out of curiousity, why did you not use the the check we use in the HubPool, that unclaimedPoolRebalanceLeafCount != 0 to detect disputes vs proposals. See the noActiveRequests modifier.
EDIT: That last idea doesn't work. I didn't quite get the nuance you picked up on, that the variables are written before the transfer. I think the way you've done it or checking the timestamp is probably the only way I could see this working. Very clever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was also my intuition, but then I tried to implement a test for it and found the opposite - it works unexpectedly. This is similarly because the pending root bundle is deleted before the bond token transferFrom() function is called, so the disputer is no longer the proposer, even though both the proposal and dispute were submitted by the same address. It's a happy accident, I guess.
For reference, see the test at line 78 in test/BondToken.e2e.ts.
That was my first attempt as well, but it doesn't work (edit: As mentioned in your update 👍). At the time of evaluation, the proposed root bundle is the version submitted by the proposer, so it seems reliably non-zero in case of both proposals and disputes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a dev comment to the BondToken.safeTransferFrom() implementation to call this out more explicitly. See 5215b60.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same question as Matt but see your point now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, it keeps getting weirder @pxrl. Really would love some validation on this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we probably don't want two contracts in the repo called WETH9 -- this causes issues in hardhat I think. Any reason we can't just delete the interface or rename it to WETH9Interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point - I'd totally missed the existing interface. I've split this out - see #227.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can we add a comment that this is the only difference between this contract and the real WETH9?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added here: edbee53.