Chain Resources
Impactium dApps should not have to depend on the public internet — npm, CDNs, GitHub — to get the code and documents they run on. Chain Resources are how Impactium hosts packages, and eventually whole repositories and living documents, on-chain: certified, content-addressed, and served by the ecosystem's own infrastructure.
Resources are $Resource
A Resource is not a new concept bolted on — it is the $Resource slot of the COA fingerprint made concrete. A Resource is a Product an Entity creates, given versioned, content-addressed releases. Each release is a manifest — its version, its publisher, and the cryptographic hashes of its content chunks — plus the bytes those hashes commit to.
Anchor on chain, serve from the tier
Putting entire package binaries into consensus state forever would bloat the chain without limit. So Impactium splits the concern:
- The chain holds the manifest — the consensus fact: what exists, at what version, published by whom, certified by whom, and the content root every byte must match.
- A resource-serving tier holds the bytes — and every chunk it serves is verified against the on-chain manifest, which in turn can be proven against the chain's committed state root.
A dApp never has to trust the server it downloads from: it verifies each chunk against a chain-committed hash. This is the same "verifiable, not trusted" discipline the whole Hive-Knowledge Graph is built on.
Certification and permanence
Publishing a release requires the Product's owning Entity to sign it. Certifying a Resource — vouching that it is what it claims to be — is a governed act (root-gated during pre-genesis, moving to a dedicated service layer as the network matures).
And like everything in Impactium, releases are append-only: a published version is never unpublished. A vulnerable release can be flagged and deprecated — visibly, with a reason — but never erased. The record of what was shipped, and what went wrong, stays.
npm install, from the chain
The gateway that serves Resources also speaks npm. A dApp adds a single line to its .npmrc:
@your-scope:registry=http://<gateway>/npm/
…and npm install resolves that scope straight from the Chain Resource gateway. Package identity comes from each artifact's own package.json (so the chain stays npm-agnostic), tarballs are assembled chunk-verified, and npm's own integrity checks pass end-to-end. On-chain deprecation flags surface as npm deprecation warnings.
Status, pre-genesis. The mechanism above is built and proven end-to-end over the real ABCI surface — register a Product, publish a content-addressed release, certify it, deprecate it — and the gateway serves packuments and chunk-verified tarballs from it. What does not yet exist is a published corpus: no package is registered on a live network, and no repository installs from the gateway. The Fancy UI kit is the intended first Resource, and this page will name its version and gateway when it is actually published rather than before.
Living documents
The same content-addressed, append-only machinery underpins living documents — the founding agreements, bylaws, and partnership terms that organizations need. A document's new versions are layered nodes, never overwrites: each version links to its parent, carries the signatures required to make it effective, and collects those sign-offs on-chain. Legal instruments become part of the permanent record, with their whole revision history intact.
Where it leads
Chain Resources start as package hosting, but the ambition is larger: certified repositories, hosted on chain like a decentralized code forge, with the act of hosting them recognized as measurable impact in its own right. The infrastructure a decentralized ecosystem depends on can be served by that ecosystem — and counted as a contribution to it.