System
Templates in, verdicts out
ReserveGrid OS takes a candidate template, evaluates it against policy, and returns a verdict object that is safe to log and display.
Deterministic
Traceable rejects
Policy visible
Flow
One contract, end to end
1. Source
Stratum v2 bridge or bitcoind produces a candidate template
2. Manager
Template manager packages it as TemplatePropose
3. Verifier
Pool verifier loads policy.toml, evaluates, emits TemplateVerdict
4. Outputs
Logs + dashboard consume the same verdict object
If a template is rejected, the verifier must explain it with a stable reason code and measurable context.
Protocol objects
Minimal surface area.
- TemplatePropose: candidate template + metadata
- TemplateVerdict: ACCEPT or REJECT + context
What “traceable” means
Rejects are only useful when they are inspectable.
- reason_code
- threshold_used
- measured_value
- tier (when fee tiers apply)
Why this is built this way
Operational sanity
Determinism
Same template plus same policy yields the same verdict.
Policy visibility
The active policy and thresholds are readable from UI and API.
Stable codes
Reason codes do not change semantics silently.