Registry — General-Purpose Key/Value Storage¶
One-line pitch: Registry is a generic on-chain key-value store. Bytes in, bytes out. Used by various game contracts for internal bookkeeping that doesn't fit a specific struct.
What this is¶
A simple registry contract: Get(key), Set(key, value), Has(key), Remove(key). Keys and values are bytes, so anything can be stored: strings, addresses, numbers, encoded structs.
Once set, a value can be removed but not overwritten — if you want to change a value you have to delete and re-insert. That immutability-at-write is a design choice: simpler to reason about who changed what.
If you've played a web3 game before¶
- Closest analogy: a generic key-value mapping contract like Ethereum's on-chain registries.
- Or: Redis on-chain — simple get/set, nothing fancy.
- Or: a namespace-aware contract-level storage module.
| Dysnomia term | What it maps to |
|---|---|
| Registry | Generic bytes → bytes store |
| Get / Set / Has / Remove | CRUD-ish interface |
| No-overwrite | Must Remove before re-Set |
What you actually do with it¶
- Nothing directly — Registry is infrastructure used by other contracts.
- Read if you know a specific key someone has registered.
Rewards / costs¶
- Cost: storage gas for Sets (non-trivial for large values).
- Reward: none — it's a utility.
Requirements & gating¶
- Owner (MultiOwnable) controls writes. Reads are public.
Where it connects¶
Used by various contracts needing flexible storage. No single "canonical consumer" — think of it as scratch space.
Quick FAQ¶
Q: Why bytes instead of typed slots? A: Generality. One Registry can serve many contracts with different data types.
Q: How much can I store per key? A: Limited by gas and block size. Practical limit: small data only (a few hundred bytes).
Want the Solidity? The contract reference lives at
technical/docs/lib/REGISTRY.md.