There is no way to confirm/verify, "over-working when above and under-working when below the peg".
There is also no way to confirm/verify I'm "working" I could spend 20 hours scrambling to fix a bug testing tons of different stuff and end up committing 15 lines of code for the week (which has happened to me before) unless I livestream all my coding sessions.
costs were estimated accordingly
But the "cost" to the chain is the same ultimately if the proposal asks for 100 hbd, it costs the chain 100 hbd if hbd is at 1$ or 100$
So anything DHF over paying could be returned to stabilizer, that’s basically what we started to do So you are still covered for development and also helping to decrease supply/increase future funding by sending back to stabilizer.
Which is a totally valid approach imho, I think it's up to each proposals to be like "I can either reduce the cost to 0 for the chain or alternatively make it so that the chain gets double the work from the proposal (if the proposal applies)"
Also regarding reducing the supply/increase future funding, while true I think it's a drop in the bucket, the hivesigner prop pays out 70 hbd per day, so half of it goes back to stabilizer, meaning 114 extra hive per day it's nothing compared to the 76 million hive from the ninja mine waiting to be converted.
hivesigner/ecency and hive in general would benefit so much more from you hiring a contractor with the extra funds to work on some new features imho.
Beside in script we can add threshold parameter for downside risk and stop returning HBD when it is 20% or 10% close to peg
Neat !
RE: My take on the increased HBD price and it's impact for proposals