You sent me down another interesting rabbit hole here with Datum.
Your five rules are basically the controller the post argues for:
- rule 3 (no share in 30s → halve) is the ease-on-silence
- rule 4 (request kS→S) is the clamp
We agree on the mechanism, which I take as a good sign. The part I want to pick up is your feedforward point, because I think it’s sharper than a delay fix. Feeding the curtailment instruction forward is free inside the operator’s own equipment — you can trust your own command. It stops being free at the proxy→pool trust boundary: there the proxy’s accurate knowledge of its hashrate is unverifiable to the pool, which is exactly why rule 4 is a request and not a command (“provided the pool respects the request”). Although that assumption would not be quite right if the proxy is 3rd party or pool-side infra, like a template/hashrate service providers.
That boundary is also the cleanest way to place SV2 vs. Datum — the difference being where the control loop lives. In SV2 the pool can run an aggregate vardiff loop: it holds an internal share-rate reference and actuates it by moving maximum_target (via periodic SetTarget). I’ve watched that loop run live on a pool terminating a direct channel — it fires and moves the target as the rate drifts. What I haven’t pinned down is, when the pool terminates an aggregating proxy (a JD-client or translator), is its aggregate loop still fed and actuating, or does it fall back to a mostly-static bound? That’s genuinely open to me — it’s the same “is the aggregate signal live or starved” question the frontier argument turns on, one layer up. Datum sidesteps it entirely: the gateway commits difficulty in the coinbase, self-certifying, so the pool holds a static floor and runs no aggregate loop at all. So the contrast is loop-vs-bound at the difficulty-conveyance layer — with the honest caveat that I’ve only confirmed SV2’s pool loop is live for a directly-terminated channel, not for the aggregating topology we’re actually discussing.
Worth adding that Datum doesn’t remove share-rate management, it relocates it. The pool’s floor covers only the direction it can verify: too-easy work floods it with shares it can check and reject, so the anti-flood bound is enforceable at the pool. The decline direction it can’t see — a slow or silent gateway produces no shares to check against — but that’s not a gap, it’s the division of labor the post is about: the pool structurally can’t own decline (no signal reaches it), so decline-safety is the frontier’s job, and Datum’s gateway does run an ordinary vardiff loop on its miners that eases on silence (60s → halve). So it’s decline-safe exactly where the post says it has to be — at the frontier, and only because that frontier loop has a ease-on-silence path. A frontier controller without one (a share-triggered-only vardiff) wouldn’t be.