Security model · v1.4.2

Assume the model is compromised. Then ask what it can do.

Every defence on this page is downstream of one assumption: on any given request, the model driving your agent is saying whatever an attacker wants it to say. Five layers narrow what that gets them. Two of the scenarios below get through anyway, and we say which.

layers 5 audits none completed contracts testnet, unaudited bounty rewards TBA disclosure 90 days
Threat model

What we are defending, from whom, and what we take on faith

A security page without a threat model is a marketing page. Here is ours, including the trust assumptions we have not managed to remove.

Assets

What is worth stealing

  • Balances in the user’s smart account.
  • Session keys and the authority they carry.
  • Agent bonds held in the vault contract.
  • The integrity of the attestation log — a forged clean record is worth real money.
Adversaries

Who we assume is trying

  • Anyone who can put text in front of the model.
  • Malicious contract authors, including upgradeable ones.
  • A compromised or dishonest solver.
  • An insider on our team with deploy access.
Assumptions

What we take on faith

  • The owner’s root key is not stolen.
  • The chain does not reorg deeper than the finality window.
  • At least one honest solver participates in each auction.
  • The signature scheme and the EVM behave as specified.
Adversaries, their capabilities and the primary control
AdversaryAssumed capability Primary controlResidual risk
Prompt injector Full control of what the model says, on every request, indefinitely. Policy evaluated outside the model against a committed hash. Anything already inside your policy.
Malicious contract Arbitrary code at the call target, including transfer hooks and re-entrancy. Forked-state simulation with balance-delta and approval-diff assertions. Logic that behaves correctly at simulated size and badly at real size.
Upgradeable proxy Legitimate today, hostile after the next upgrade transaction. Implementation-slot fingerprinting against the attested hash. A window of one block between upgrade and our re-attestation.
Dishonest solver Quotes a price it cannot honour, or front-runs the intent it is quoting. Sealed bids, mandatory pre-award simulation, solver bond forfeited on miss. Collusion among every solver in one auction.
Key thief Exfiltrates a live session key from the agent host. Capability scoping plus a four-hour default expiry. One in-scope action per key until it expires or is revoked.
Insider Deploy access to our infrastructure and the token contracts. 48-hour timelock on upgrades; policy enforcement lives in your account, not ours. Off-chain services — API, indexer — can be degraded immediately.
Oracle manipulator Can move a thin market for two blocks. Deviation bands against a second source; staleness bounds. Real. See scenario 05 below.
The stack

Five layers, each with a column we would rather not write

Every layer can independently refuse an action, and every refusal is recorded. Expand a layer for what it catches — and for what it demonstrably does not.

The agent never holds a key with unlimited authority. It operates a smart account whose validation logic the owner controls, and receives session keys scoped by capability: an asset set, a venue set, a notional ceiling and an expiry. Scope is checked in validateUserOp, before any call executes, so an out-of-scope action reverts rather than being caught after the fact.

Catches

  • Any call to a venue outside the key’s capability set.
  • Any transfer of an asset the key was not issued for.
  • Use of a key past its expiry, without needing a revocation transaction.
  • Attempts by the agent to issue itself a wider key.

Does not catch

  • Anything the key was legitimately allowed to do — a stolen key is a bounded loss, not zero.
  • Actions taken by the owner key itself. It is the root of trust.
  • Bundler censorship or ordering games; that is layer 04’s and the solver’s problem.

Caps, allow-lists and guards are committed as a hash. The executor loads the policy body, verifies the hash, and refuses to act if they disagree. The model never reads the policy, so it cannot be argued into a different one; changing it is a signed, timestamped transaction from the owner.

Catches

  • Notional above per-transaction or rolling daily caps.
  • Counterparties and contracts outside the allow-list.
  • Slippage bands, gas ceilings and oracle-staleness bounds.
  • Prompt injection asking for anything you did not already permit.

Does not catch

  • A loose policy. If you allow $5,000 swaps without approval, an attacker gets one.
  • An honest agent executing a bad strategy inside its limits.
  • Economic manipulation that makes a bad price look like a good one — see layer 03.

Every candidate route runs against a fork of current state before it can win the auction. We assert on balance deltas and approval diffs rather than on the return value of the call, so a contract that reports success while draining the caller fails the assertion.

Catches

  • Malicious transfer hooks and re-entrancy against the caller.
  • Routes that would revert, before they ever reach a mempool.
  • Unexpected approval grants left behind by a call.
  • Stale oracles, by freshness bound.

Does not catch

  • Contracts that behave correctly at the simulated size and badly at another.
  • Time-bombed logic keyed to a block number after the simulation.
  • A manipulated but fresh oracle. Freshness is not correctness.
  • State that changes between simulation and inclusion, beyond the bounds we assert.

Target contracts are fingerprinted against a registry of attested bytecode. For proxies we fingerprint the implementation slot, not the proxy address, which is what makes a post-audit upgrade visible. Unknown targets are not blocked outright; they are flagged and subject to a lower notional ceiling.

Catches

  • Proxy upgrades to unattested implementations.
  • Known-malicious bytecode and honeypot patterns.
  • Address-poisoning lookalikes on the counterparty list.
  • Contracts deployed within the last 24 hours, by policy default.

Does not catch

  • Novel malicious code that has never been seen and passes simulation.
  • A legitimate contract whose owner turns hostile without an upgrade — configuration, not code.
  • Off-chain components of a target protocol.

Above a threshold you set, execution pauses for explicit approval. The agent waits; it does not retry around you, and it cannot lower the threshold. Every hold is recorded on the passport with the rule that fired, so the pattern of what gets held is itself readable.

Catches

  • Anything above your notional threshold, whatever the cause.
  • First interaction with a new counterparty, if you enable that guard.
  • Anomaly signatures: unusual hour, unusual venue, unusual size for this agent.

Does not catch

  • Anything below the threshold — which is most things, by design.
  • Approval fatigue. A threshold set too low trains you to approve without reading.
  • An attacker who already controls the approval channel.
Attack walkthrough

Six scenarios. Four are stopped. Two are not.

Pick an attack and watch it walk the stack. The trace shows what each layer actually evaluated, not a cartoon of it.

Audit status

No audit has been completed. Every contract is unaudited.

No firm is engaged, no report exists and nothing on any testnet has been reviewed by anyone outside this team. Below is the scope in the order we intend to hand it over, published now so the order is on the record before the engagement is.

Planned external audit scope by component
ComponentScope Holds valueStatus
Settlement + registry Settlement path, minimum-output enforcement, fee split, registry writes. YesSCHEDULED
Account + session keys ERC-4337 validation, capability-to-selector map, expiry and revocation. YesSCHEDULED
Bond vault + arbitration Bond accounting, slashing execution, the seven-day challenge window. YesNOT STARTED
RWA token + allow-list Permissioned transfer hooks, register reconciliation, corporate-action freeze. YesNOT STARTED
Indexer + API No funds and no signing authority — but it can still misreport what happened. NoNOT STARTED
Read this before you send anything to a testnet contract

Unaudited means unaudited. The contracts are redeployed without notice, the invariant suite is our own work marking our own homework, and no external reviewer has looked at any of it. Nothing on a Strix Hood testnet should hold value you would miss. Reports will be published in full — including findings we dispute and findings we accept but have not yet fixed — at the same time they are delivered to us.

Continuous

Invariant suite

Runs against every commit under Foundry fuzzing. A new invariant ships with the feature that needs it and the suite is not allowed to shrink. It is our own work marking our own homework — it is not a substitute for the audits above and we are not going to present it as one.

Continuous

Attack corpus

Recorded malicious payloads replayed against the simulator nightly. The safety score on a passport is the fraction of the corpus that agent refused, so the number only means as much as the corpus does.

Quarterly

Chaos suite

Reorg replay to depth 32, RPC failover, solver withdrawal mid-auction, certificate rotation. It grows whenever something teaches us a new failure — so far only from testing, because nothing has failed in public.

Bug bounty

Severity and response times are set. Rewards are not funded yet.

There is no cash bounty today, and we are not going to publish a number we cannot pay. The severity ladder and the response clock below are in force now; the reward column is set when the programme is funded at mainnet. Scope is every contract in the registry, the policy engine, the session-key validator and the settlement path. Out of scope: this website, the testnet faucet, and anything requiring the owner’s root key.

Bug bounty severity tiers
SeverityDefinitionExample RewardFirst response
CriticalDirect theft of user funds or agent bonds, or minting without collateral. Session-key validator accepts a forged scope.TBA4 hours
HighGriefing that permanently locks funds, or bypass of a single enforcement layer. Policy hash check bypassed for one intent type.TBA12 hours
MediumTemporary denial of service, or forcing an incorrect but recoverable state. Auction stalls when a solver disconnects mid-quote.TBA2 days
LowInformation disclosure or an inconsistency with no direct path to loss. Refusal reason leaks an allow-list entry.TBA5 days
InformationalHardening suggestions, documentation errors that could mislead. A stated default that does not match the code.credit10 days
What you get instead of money, for now

The response clock above is a commitment we can keep today: a human reply inside the stated window, a named fix or a named refusal, and public credit in the disclosure log unless you ask us not to. When the reward schedule is funded it will be published here with the amounts filled in, and it will apply retroactively to anything still unpaid.

Rules

  • Testnet only. Do not touch mainnet contracts or other people’s accounts.
  • No denial of service against live infrastructure; describe it instead and we will reproduce it.
  • First report wins. Duplicates get credit, not payment.
  • We will not sue you for good-faith research within these rules, and that commitment is in writing.
  • Public disclosure after a fix ships, or 90 days, whichever comes first — your choice of timing within that.

How to report

Encrypted mail preferred. Include a reproduction, the commit hash and the impact you believe it has. A proof-of-concept transaction on testnet is worth more than three paragraphs of description.

PGP key and fingerprint · published in the repository root and at /.well-known/security.txt

Disclosure policy

What we commit to when something goes wrong

These are commitments, not a track record — nothing has gone wrong in public yet because nothing is in public production yet. If we miss one, the postmortem on the status page will say so explicitly.

  1. Acknowledge within 4 hours for anything critical. A human replies, not an autoresponder. The clock starts when the report arrives, not when we open it.
  2. Publish an initial notice within 24 hours of confirming user impact. Even when we do not yet know the cause. “We do not know why” is publishable; silence is not.
  3. Ship the fix before the disclosure, if a fix is possible. Where it is not — an economic issue rather than a bug — we disclose with the mitigation you can apply yourself.
  4. Full postmortem within 5 working days. Impact, timeline, root cause, and what changed. Published on the status page and never quietly edited afterwards.
  5. 90-day maximum embargo. After 90 days the reporter may publish regardless of our fix status. We will not ask for an extension more than once, and we will say publicly that we asked.
  6. Name the missed commitment. Where we break one of the five rules above, the postmortem says which one and by how much, in its first paragraph, before the root cause. A commitment that is only quoted when it was met is marketing.
Honest limits

What none of this protects against

Every item below is a real, current gap. Where a mitigation exists it is outside this stack, and we say what it is.

  • Owner key theft. Whoever holds the owner key can rewrite the policy, widen every scope and disable human-in-the-loop. No protocol layer can stop the root of trust. Mitigation: multi-sig or hardware owner, plus the guardian timelock landing in v1.5.
  • A policy that is too loose. The most common real-world loss is not an exploit; it is a $50,000 daily cap on an agent that only ever needed $500. Mitigation: start at a tenth of what you think you need.
  • Oracle manipulation with a fresh price. Our freshness checks confirm the oracle is current, not that it is right. Deviation bands narrow the window; they do not close it. Mitigation: low approval thresholds on illiquid pairs.
  • An agent that is honest and bad at its job. Nothing is slashed, because no promise was broken. The protocol bounds behaviour, not competence.
  • Chain-level failures. A reorg deeper than the finality window, a sequencer halt, or a consensus bug is outside anything we control.
  • Off-chain service compromise. Our API and indexer cannot move your funds, but they can show you a false picture of what happened. Verify against the chain for anything material.
  • Social engineering of you. An approval prompt you did not read is an approval.
  • Regulatory action against the RWA structure. A forced redemption is a real scenario for tokenized equities and is described on the stocks page.
Why this list is on the marketing site

A security model you cannot check is a claim. Publishing the gaps is the only way the claims about what we do stop mean anything, and it costs us nothing we should want to keep.

Shipping next
  • v1.5 · guardian timelock — policy edits delayed 24 hours with guardian veto, reducing owner-key blast radius to the timelock window.
  • v1.5 · dual-oracle mandatory — deviation bands become non-optional for pairs below a liquidity floor.
  • v1.6 · attestation proofs — prove an execution complied with a policy without publishing the policy.

Find something we missed.

The contracts are public and unaudited, the invariant suite runs on every commit, and the reward schedule is not funded yet. Report it anyway — findings are credited, published, and paid retroactively when the programme is funded.