on-chain commitments for hum — slashable identity, manifest pointers, future settlement

Solidity contracts that pair with hum's off-chain mesh layer (ensemble). The wire stays high-frequency and free; the chain stores commitments about that wire — provable, signable, auditable.

The interface — IHumdRegistry.sol — is what hum considers canonical. Anyone can deploy a contract that implements it. Off-chain clients (the Rust ensemble::onchain module, future TS/Python/Go clients) read against the interface, not against a specific deployment.

That means:

• No canonical hum-maintainer deployment. There is no single registry address everyone shares. The repo ships HumdRegistry.sol — the vanilla reference implementation — but it's just one possible implementation.
• Subnets are first-class. A hackathon team, a single org, or a free agent deploys their own address on whatever chain they like. Their humds read/write only that address. Other subnets are isolated by address.
• Policy lives in the implementation. Want allowlisted advertise? Stake-on-advertise? Name aliases? Write a contract implementing IHumdRegistry with those rules. All humds keep reading you the same way they read the vanilla.
• No hum-side governance required. None of the contracts in this repo today have owner functions, multisigs, or upgrade paths. Deploying one is a one-time act.

Most of thrum is unsuitable for chain — text streamed at 10–100 Hz is not a transaction. Three things have natural on-chain homes:

Today the repo ships HumdRegistry. The other two follow the same interface-as-standard pattern when they land.

contracts/
├── src/
│   ├── IHumdRegistry.sol    # the interface — the standard
│   └── HumdRegistry.sol     # vanilla implementation
├── test/
│   └── HumdRegistry.t.sol   # forge tests against the vanilla impl
├── foundry.toml             # build config
└── README.md

Uses Foundry. One-time install:

curl -L https://foundry.paradigm.xyz | bash
foundryup

Then:

cd contracts
forge install foundry-rs/forge-std --no-commit   # one-time, populates lib/
forge build
forge test -vv

Default RPC targets are wired in foundry.toml. Deploy the vanilla implementation to Arc testnet:

export PRIVATE_KEY=0x...
forge create --rpc-url arc_testnet \
  --private-key $PRIVATE_KEY \
  src/HumdRegistry.sol:HumdRegistry

forge create prints the deployed address. Hand it to your humds and bees:

export HUMD_REGISTRY_ADDR=0xthe-address-forge-just-printed
export HUMD_REGISTRY_RPC=https://rpc.testnet.arc.network

That's the whole onboarding. Your subnet's humds use that address; other subnets use theirs. Isolation by address — no shared coordination needed.

ensemble::onchain::HumdRegistryClient (Rust) reads any IHumdRegistry-shaped contract via plain JSON-RPC eth_call — no alloy / ethers-rs dependency. See ensemble/src/onchain.rs.

Typical flow:

1. A humd computes keccak256(manifest_json_bytes).
2. It uploads the manifest JSON to IPFS (or any reachable HTTPS URL).
3. It calls advertise(pubkey, hash, uri) on its subnet's registry — one tx, ~50k gas.
4. Other humds in the same subnet read the registry, fetch the URI, verify the hash, and now have a manifest they can trust without trusting the off-chain gossip layer.

The contract only stores claims. Verification is:

The vanilla implementation makes no claims beyond that. Slashing, ed25519-signature verification, name resolution — all opt-in by swapping in a richer implementation of the same interface.

• ensemble/src/bees.rs — the off-chain manifest type these commitments are about.
• ensemble/src/onchain.rs — Rust client. Reads against the interface, works with any implementation.
• WIRE.md — the protocol the manifest describes.
• adiled.github.io/hum — docs site.