Protocol · Threat model
Who attacks Foundry, how, and what stops them.
A protocol that mints share certificates on-chain is a magnet for adversaries. This page enumerates the attack surface we've thought through, the mitigations in place, and the known gaps we are accepting in v1 and tracking on the roadmap.
Scope
This threat model covers the six on-chain contracts, the eval coordinator, the SDK, and the indexer. It does not cover the client-side wallet you use to sign transactions — that's your infrastructure.
Adversaries
| Adversary | Goal | Capability |
|---|---|---|
| Greedy Smith | Inflate own shares by submitting duplicate or low-effort data. | Has a wallet. Can spam the registry. |
| Coordinator collusion | Sign false attestation that overpays specific contributors. | Runs (or compromises) the TEE. |
| Inference siphon | Call an Ingot in a way that bypasses RevenueSplitter. | Network-level access; eth_call manipulation. |
| Lineage forger | Mint a child Ingot claiming a parent that didn't authorize it. | Can deploy contracts that look like Forges. |
| Sybil funder | Open many Forges to grief the coordinator into wasted compute. | Cheap wallet creation. |
Attack surface
| Vector | What it targets | Severity |
|---|---|---|
| Duplicate data contribution | ContributionRegistry | Medium |
| TEE attestation forgery | Forge.submitEvalResult | Critical |
| Replay attack on attestation | Forge.submitEvalResult | High |
| Front-running fundForge | Forge.contributeCompute | Low |
| Re-entrancy in claim | RevenueSplitter.claim | High |
| Inference proxy bypass | off-chain inference path | Medium |
| Fake parent Ingot | Ingot.lineageParent | Medium |
Mitigations
| Threat | Mitigation |
|---|---|
| Duplicate data contribution | Each contribution is keyed by a content hash committed at submission. The eval coordinator's training pipeline dedupes by hash before LOO. Score(duplicate) = 0. |
| TEE attestation forgery | The Forge stores the public key of the registered TEE provider at createForge. submitEvalResult verifies the signature on-chain. Forging requires both compromising the TEE itself and re-registering the provider — the latter is governance-gated. |
| Replay attack on attestation | Each Forge issues a one-shot nonce committed in OPEN → TRAINING. The attestation must include it; the Forge rejects mismatched nonces. |
| Re-entrancy in claim | Pull-payment pattern: claim() uses checks-effects-interactions, debits the holder's balance before transferring, and applies the OpenZeppelin nonReentrant guard. |
| Inference proxy bypass | The OpenAI-compatible proxy is the only path that triggers RevenueSplitter.deposit(). Calling an Ingot directly (e.g., running the weights locally) is permitted but does not earn revenue. Co-owners hold the model; nobody can take that away. |
| Fake parent Ingot | The lineageParent field is set at mint by the child Forge. The child Forge must produce a TEE attestation that consumed the parent's weights root as input. Forging a parent requires forging a TEE attestation — collapsed into "TEE attestation forgery" above. |
Re-entrancy belt and suspenders
RevenueSplitter is the most adversarially-exposed contract because it ships ETH outward. We apply three independent defenses: checks-effects-interactions, OpenZeppelin's nonReentrant, and a cap on per-tx claims. Each defense alone is sufficient. The stack is intentional redundancy, not paranoia.
Out of scope (v1)
These are real threats we are choosing not to address in the v1 launch. Each is tracked on the roadmap.
- Adversarial training data. A Smith could submit data poisoned to insert a backdoor into the model. LOO scoring would actually punish them (eval drops), but a sophisticated attacker could craft data that helps the eval and hurts a downstream task. v1 mitigation: human review of high-impact contributors. v2 mitigation: pre-eval adversarial probe.
- Inference oracle gaming. A builder could call the same Ingot many times to inflate its revenue and pump its perceived value. v1 mitigation: dashboard flags suspiciously concentrated callers. v2 mitigation: rate-limit + economic friction.
- Compute-side collusion. A compute provider that also Smiths could route their own data preferentially during training. The TEE prevents this in principle (the training container is sandboxed), but in practice depends on the host's integrity. v1: trust the 0G Compute attestation. v2: require GPU attestation per-batch.