Previous HBD stabilizer proposals have grown with available funding from DHF. With this proposal, funding is being scaled back, with the intent that it operate as a more ordinary DHF proposal and no longer as a substitute for the "return proposal", absorbing all available budget.
As such, there is room for other community members to propose (and, if they choose, stakeholders to approve) their own HBD stabilizer proposals. Having multiple independent proposals would likely make the system more resilient (if one stabilizer bot had downtime, as has occasionally occurred, others would keep going). It also reduces the exposure to a single stabilizer bot getting hacked or the operator going rogue and running off with some funds (ongoing funding would stop as soon as someone noticed and stakeholders unvoted it, but some damage could already be done).
Although the implementation I am using is not open source, the algorithm is open source and others are free to copy it, use it as the basis for their own stabilizer implementation or proposals, and/or improve on it. It is quite basic and can likely be improved, both in terms of peg-supporting and in terms of profit generated and returned to DHF.
In addition to the now slimmed-down budget, the stabilizer recipient account for this proposal will continue to accept, power down, use for stabilizing, and return to DHF, any beneficiary rewards sent to it by the @hbd.funder account, as well as any other beneficiary rewards or other donations to the @hbdstabilizer account.
Important note: since this proposal will no longer consume all available funding, stakeholders should direct some renewed attention at the voting of the return proposal
Proposal number 264
Hivesigner link to approve
Peakd proposal link
Ecency proposal link
100% beneficiary to @hbdstabilizer