Staking And Registration
How Base registry state binds B3IQ nodes, model hosting, owner identity, active status, and stake policy.
Stake makes operator reputation economically meaningful. B3IQ uses Base as the near-term chain for B3 stake and node/model registry state.
Node Registration
A protocol-ready node needs:
The node ID is registered in the Base registry and bound to an owner.
Registry state marks the node active.
The node satisfies the current minimum B3 stake policy.
Registry readiness is necessary but not enough; route, runtime, model, and benchmark gates still need to pass.
Deployed Registry
B3IQ registry tooling exists for Base mainnet node registration and staking visibility. Public docs and explorer views should keep chain context explicit.
0x7F94...67d4
↗
Model Hosting
B3IQ separates model publisher commitments from node hosting capability:
- Model publisher commitments can include artifact hash, metadata URI, publisher stake, status, and model-level slashing boundaries.
- Node model-hosting capability can include node/model/runtime/benchmark/route commitments.
- Raw inventory, endpoints, filesystem paths, prompts, and outputs stay out of public commitments.
Capability Commitments
The target b3iq-capability-v1 commitment is public-safe. It can hash:
- Node ID.
- Model class.
- Runtime class or runtime hash.
- Benchmark hash.
- Route class.
- Privacy class.
- Metadata URI.
It must not include raw local endpoints, runtime IDs, paths, private routes, prompts, outputs, or secrets.
Slashing Boundary
Slashing is last resort. Refund, release, withhold, suspension, and reputation paths should handle normal operational failures. Slashable conditions need clear evidence standards, appeals, and public-safe reason strings.
See Reputation for dispute policy.