Security and threat model

Impactium states its security posture as an explicit threat model, not a slogan. This page names what the network defends against, how, and — just as importantly — what it does not yet defend against. If a guarantee is structural, we say so; if it is a trust boundary, we name it.

The first line of defense: structural invariants

Impactium's core guarantees are enforced by the framework, not by developer discipline — the Impact SDK is written so they cannot be violated:

• Impact is non-transferable — the Capsule type has no operation to move it; there is nothing to exploit because there is no transfer path.
• Impact is permanent — there is no deletion or pruning path in the state layer.
• Execution is deterministic — no floating point, no wall-clock, no unordered iteration into committed state, so every honest node computes an identical result.
• Failures commit visibly — a rejected impact claim is recorded with its reason, never silently dropped.

A whole class of attacks (mint-and-drain, quiet rewrites, hidden negative outcomes) simply has no surface here, because the capability it would need does not exist in the type system.

Transaction security

Every transaction passes a pre-execution pipeline before any handler runs:

• Signature verification (secp256k1) binds each transaction to its signer's key.
• Replay protection via a per-Entity sequence — a captured transaction cannot be re-submitted.
• Spam is bounded without gas. Because Impactium has no tradeable token, it cannot charge fees. Instead each signer has a non-transferable capacity budget that refills over time; it cannot be hoarded, transferred, or drained by an attacker on someone else's behalf. Malformed input is rejected before it can consume a victim's budget.

Module isolation

The application is a set of modules, each confined to its own state namespace and declaring exactly which other modules it may read. Undeclared cross-module access is impossible — it is rejected at dispatch, by construction. This bounds the blast radius of a bug: a fault in one module cannot silently corrupt another's state.

Consensus and validators

Consensus is CometBFT (BFT): safety holds while more than two-thirds of validator power is honest. Impactium's validator set is governed and vetted — power is assigned to known, accountable Entities, not bought with stake. That is a different trust model than proof-of-stake, with its own defense: admission is deliberate, and influence is shaped by governance and proximity rather than capital, which is designed against the concentration failure mode that reputation and stake systems both risk. It does not inherit proof-of-stake's economic "cost to attack" argument, and we do not claim it does.

The trust boundary we name plainly

During the vetted-validator era, node operators hold the plaintext state they validate. So granular privacy is a trust boundary, not yet a cryptographic guarantee — while existence and net impact position are public by design. End-to-end on-chain encryption with selective disclosure is a firm gate on Genesis — the record does not become permanent without it; until it ships, the honest posture is a known, vetted operator set, stated openly rather than papered over. See Verifiable, not trusted for what you can check without trusting anyone.

Threat model at a glance

Threat	Mitigation
Transaction replay	Per-Entity sequence checked before execution
Spam / resource exhaustion	Non-transferable per-signer capacity budget (no gas)
Forged transactions	secp256k1 signature verification
Cross-module state tampering	Namespaced modules + declared, dispatch-enforced read permissions
Hiding a negative or failed claim	Visible-failure invariant — rejections commit permanently
Compromised dApp code / supply chain	Chain Resources: content-addressed, chunk-verified against on-chain hashes
Tampered read layer	Karma is disposable — replay the chain, or escalate any fact to an ICS23 proof
Validator collusion	<1/3-Byzantine safety + vetted, proximity-shaped admission (a named, evolving boundary)
Personal data exposure	No-PII-on-chain policy; opaque identifiers; detail gated (see Privacy)

Responsible disclosure and audit posture

Impactium is pre-genesis: development networks reset freely and nothing here is permanent yet. Permanence begins at Genesis, and the encryption gate above is one of its conditions — so the trust boundary named on this page is a property of the phase we are in, not of the system we are building. External security audits are planned before any public incentive or value-bearing interaction, with the audited commit and scope published alongside the report rather than a generic "audited" badge. If you find a security issue, report it privately through the project's disclosure channel rather than filing it publicly. As the network approaches Genesis, this page will carry the concrete disclosure address, bug-bounty status, and audit artifacts.