docs/the-impact-sdk.mdpinned to impactium@637886d

The Impact SDK

Impactium is not built on an existing chain framework. Its foundations — impact as value, non-transferable capsules, referral-only wallets, multi-root partitions, the accountability/impact chains — have no equivalent in general-purpose blockchains. So the chain is built from scratch on a purpose-made Impact SDK, in Rust.

Why a custom SDK

Adopting a conventional smart-contract chain would mean bending Impactium's core invariants to fit tools designed for tradeable tokens and profit-seeking applications. Instead, the invariants are made structural — enforced by the framework itself rather than by convention:

  • Capsules are non-transferable by construction — the type has no transfer method to disable.
  • Impact is permanent — there is no pruning path in the state layer.
  • Execution is deterministic — no floating point, no unordered iteration into committed state, so every node computes an identical result.
  • Failed impact claims commit visibly — rejections are recorded, not discarded.

These are not policies a developer must remember to uphold; they are properties the SDK will not let you violate.

The shape of it

The SDK cleanly separates the framework from the application:

  • The framework provides the state store (a Jellyfish Merkle Tree with ICS23 proofs, in memory for testing and crash-atomic on disk for nodes), the module router with per-module isolation, the transaction pre-execution pipeline (signature, replay protection, and non-transferable spam metering), and the ABCI server that speaks to consensus.
  • The application is a set of modules, each owning one concern: identity, referral spawning, minting, capsules, the constitution, notarization, weights, true-cost, validators, and on-chain resources. Modules are isolated by default and declare exactly which other modules they may read.

Consensus

Impactium uses CometBFT for BFT consensus, driven out-of-process through ABCI 2.0 — the same proven pattern used by mature application-specific chains. Consensus orders and finalizes blocks; the Impact SDK application decides what those blocks mean. Validators are not open bonded-stake: they are a governed, vetted set (power is assigned, not bought), which suits a network where participants are known, accountable Entities.

No fungible gas

Because Impactium has no tradeable token, it cannot charge gas the usual way. Spam is bounded instead by a non-transferable, per-signer capacity budget that refills over time — a rate-limit that stands in for fees without introducing a currency to buy or sell. It cannot be transferred, hoarded, or drained by an attacker on someone else's behalf.

The base of two layers

The Impact SDK is Impactium's base layer (L1) — settlement and the permanent record. Applications run on a purpose-built execution layer (L2) above it, built to Impactium's own invariants. The same structural rules — non-transferable, permanent, deterministic, failures-visible — hold on both layers. See Architecture: Layers for the full map.

Clients are generated, not hand-written

Every client — the wallet, the ledger, and the apps built on the execution layer — is generated from the SDK's own protocol definitions, so the wire contract is shared and versioned across languages. A transaction signed by a TypeScript wallet is byte-for-byte identical to what the Rust chain expects, proven against a committed signing vector. There is no separate, drift-prone SDK to maintain per language.