Security & risks

This page lays out the threats VIGIL is designed against, what each mitigation actually buys, and where the protocol offers no protection. It also states the current status of the contracts and how to report a vulnerability.

Trust assumptions

VIGIL reduces the trust an agent must place in a provider. It does not remove trust from the system; it moves it to parties that can be checked and punished. The protocol assumes the following.

• Base produces blocks and finalizes them. Attestations, scores, and escrow state live onchain and inherit the chain's guarantees.
• A majority of active stake, after the per-Watcher cap, is honest. Scores and dispute outcomes are stake-weighted, so this is the core assumption.
• The VIGIL Facilitator relays payments and responses faithfully. It cannot move escrowed USDC except along the state machine in Escrow flow, but it can refuse to act.
• USDC on Base behaves as a stablecoin. VIGIL takes no position on that.

The threats below are what happens when one of these is stressed.

Threat model

Colluding Watchers

A group of Watchers publishes coordinated false Attestations to inflate a bad endpoint or bury a good one.

Mitigations:

• Stake-weighted aggregation with a per-Watcher cap. No single Watcher contributes more than 10% of the weight for an endpoint, whatever its stake. A cartel must control many separately staked identities to dominate a score.
• Region diversity. The reference Probe runs from at least 3 regions. Attestations that agree with each other but disagree with other regions are flagged for review.
• Minimum distinct Watchers. A score is public only after at least 25 Attestations from at least 5 distinct Watchers. A single operator cannot publish a score alone.
• Disputes and slashing. Any staked Watcher can open a dispute within 24 h. The dispute is settled by a stake-weighted vote over 48 h, and the losing side's Attestations are slashed by a fraction of stake defined by governance. Collusion has to beat the rest of the staked network, and the cost of losing is real.

Residual risk: a cartel that controls a majority of capped stake can still win disputes. This is the majority-honest assumption above, made explicit.

Provider gaming probes

A provider detects probe traffic and serves fast, well-formed, correctly priced responses to Probes while serving degraded responses to everyone else.

Mitigations:

• Probes are indistinguishable from real calls. A Probe pays real USDC through the same facilitator path an agent uses. There is no probe header, no allow-listed key, and no special wallet. The provider sees an x402 payment and a request, the same as any other.
• Rotating regions and keys. Probe wallets and egress regions rotate on a schedule that is not published.
• Attestations from real escrowed calls. Every payment routed through the Facilitator produces the same four checks as a Probe. Those results are attested too. A provider that games Probes but fails real calls is scored down by its real customers.

Residual risk: a provider that behaves well for every paying caller is, by definition, a good endpoint. VIGIL measures behaviour under payment, not intent.

Prompt-injected agents

An agent is tricked, through injected content, into calling an endpoint it should not, or into paying more than it should.

Mitigations:

• Score gate. An agent that refuses to call endpoints below a chosen band never reaches most malicious endpoints, because a malicious endpoint has to earn a score first, under continuous probing.
• Escrow limits the loss. If the response fails any check, the agent is refunded automatically and loses nothing. If the response passes the checks but is useless, the agent loses exactly the quoted price, once. The provider cannot charge more than it quoted, cannot charge without responding, and cannot respond with the wrong shape.

What is not mitigated: VIGIL does not judge semantic usefulness. A response that matches the schema, arrives within the deadline, fits the size budget, and is charged at the quoted price is released, even if its content is wrong. Protecting an agent's reasoning from injection is the agent developer's job. See Agent developers.

Facilitator availability

The VIGIL Facilitator is currently a single service. If it is down, agents that route through it cannot pay.

Mitigations:

• Fallback to direct x402. The client packages fall back to paying the endpoint directly when the Facilitator does not answer. The agent loses escrow protection for that call but keeps working. Fallback is opt-in and logged.
• No custody beyond the escrow window. USDC sits in the escrow contract, not with the Facilitator, and only between Locked and Released or Refunded. An unresponded escrow refunds automatically after the deadline the agent set, default 30 s and at most 300 s. A Facilitator outage cannot strand funds indefinitely.

Residual risk: liveness, not safety. A prolonged outage is a denial of service against escrow, not a theft.

Escrow contract risk

The escrow contract holds USDC between Locked and settlement. A bug in it is the highest-severity failure in the system.

Mitigations planned, not yet in place:

• Independent audit before mainnet deployment.
• Minimal surface: the contract implements the state machine and nothing else. Scoring, disputes, and fees are separate contracts.
• Time-bounded exposure: funds are never held longer than the deadline plus the 10 s check window plus, in a dispute, the 24 h Disputed window.
• Per-call caps on escrow size during the initial mainnet period.

There is no upgrade key planned for the escrow contract. If a flaw is found, the fix is a new deployment, and clients migrate.

Status

Status changes will be reflected here and announced on x.com/VigilOnBase. Until an audit report is linked from this page, treat every claim in these docs as a design, not a guarantee.

Responsible disclosure

If you find a vulnerability in the design, the reference implementations, or, once deployed, the contracts, report it by direct message to @VigilOnBase on X. That is the only channel. There is no email address, bug tracker, or chat server, and anyone claiming to accept reports through one is not VIGIL.

Include what you found, how to reproduce it, and how you would like to be credited. Please do not test against other people's escrows or publish details before a fix is confirmed. Rewards for valid reports will be described once contracts are live.