Closed McDaan closed 1 month ago
this is intended behavior. Since stewards are trusted (cause they have been elected by the community), they have the power to create pgf funding proposals which pass by default. If half of 1/3 of the total voting power is voting nay, the funding will fail. 2/3 of the voting power is voting nay, then the funding fails and the steward is removed from being a steward.
this is intended behavior. Since stewards are trusted (cause they have been elected by the community), they have the power to create pgf funding proposals which pass by default. If half of 1/3 of the total voting power is voting nay, the funding will fail. 2/3 of the voting power is voting nay, then the funding fails and the steward is removed from being a steward.
If no quorum is needed in theory, shouldn't the "total voting power needed to tally" while querying be just 0 if it's intended to pass by default? I mean, if it's an intended behaviour, from a user perspective, I think it could be odd to see props with no "apparent" sufficient social consensus, like prop results query on CLI it's not even displaying the default thing or is having non complete info in regard to this specific tally type design, which focuses on the veto instead of the proposal passing itself.
If no quorum is needed in theory, shouldn't the "total voting power needed to tally" while querying be just 0 if it's intended to pass by default? I mean, if it's an intended behaviour, from a user perspective, I think it could be odd to see props with no "apparent" sufficient social consensus, like prop results query on CLI it's not even displaying the default thing or is having non complete info in regard to this specific tally type design, which focuses on the veto instead of the proposal passing itself.
Yeah this makes sense, agreed that the log is misleading. This seems to just have been an unintended consequence of how the code is structured, will try to adjust the log / code clarity in this case.
And just to be clear, tnam1qr2rdpsxe4uxgxqeu27pdp289sxe8fh7zy3hckmg
is a steward, right?
@Fraccaman I think that ca0699f1dd9bc1e10fc57eb01002508e19264cd3 solves this issue to a degree
And just to be clear,
tnam1qr2rdpsxe4uxgxqeu27pdp289sxe8fh7zy3hckmg
is a steward, right?
Yes, that's correct.
namadac query-pgf
Pgf stewards:
- tnam1qr2rdpsxe4uxgxqeu27pdp289sxe8fh7zy3hckmg
Reward distribution:
- 1 to tnam1qr2rdpsxe4uxgxqeu27pdp289sxe8fh7zy3hckmg
[...]
On the current Campfire iteration
tududes-test.81efb06d86523ae4f
running on the mainnet release candidatev0.40.0
, I was digging into PGF type proposals to further improve Undexer/Shielded Live explorer by providing info/feedback in regard to the proposal data. While doing so, I just encountered, which in my opinion is a critical bug or serious at least, because it allowed me to intentionally drain all tokens sitting on thepublicgoodfundings
internal address to a different address than the steward one.I have been reading the specs, and I found that semantic is somehow confusing toward this, so I took the tally type literal definition to figure it out. A pgf payment proposal submitted by a steward address has this tally type:
LessOneHalfOverOneThirdNay
, which means:In this case, there were no votes, no quorum/tally reached (1/3 at least), i.e. no social consensus at all - it basically allows to a malicious actor to potentially stole all tokens on
publicgoodfundings
internal address.This is the pgf payment proposal submitted by the steward address:
Balance of address
test2
was 0 initally.Balance of
publicgoodfundings
internal address few epochs before pgf payment proposal has been submitted:Balance of address
test2
after pgf payment proposal passed (exact amount as requested via rpgf on the proposal):Balance of
publicgoodfundings
internal address few epochs later:Result: the
publicgoodfundings
internal address has been drained intentionally through a pgf payment proposal that passed without even have reached the required quorum/tally specified on the tally type (1/3 at least).