Frequently asked

Attentra watches Solana DeFi protocols and publishes a continuously updated risk score for each one. The score reflects the protocol's current operational health — things like whether its multisig has been quietly modified, whether its price oracles look healthy, whether its program code has been changed without a proper governance process. The score and the underlying findings are published on-chain, where any other system — a lending market, a wallet, an insurer's risk engine — can read them and act on them.

Concretely: a Solana protocol you'd recognize loses about $625 million per month to silent operational compromises. Attentra is a signal to catch those before users get hurt.

Five groups, in roughly the order they get the most value: insurance underwriters who need a real-time signal to support DeFi coverage; lending markets that want to gate collateral based on protocol health; custodians and exchanges that need diligence inputs at scale; risk engines that consume Attentra alongside their own analytics; and wallets that want to warn users before they sign a transaction with a flagged protocol.

Monitored protocols themselves can also subscribe — to receive early alerts when our system detects a change, and to participate in the dispute and override-acknowledgment processes we describe below.

Solana, today. The methodology is designed around Solana-specific structures — Squads multisigs, Solana's program upgrade model, Pyth and Switchboard oracles. Ethereum and L2 support is planned for a later version of the methodology, with checks adapted for how those chains work.

A traditional audit is a snapshot — it tells you a protocol looked safe on the day the auditors looked. Attentra is the continuous heartbeat that comes after. We don't replace audit firms; we sit alongside them. STRIDE (the ecosystem's leading credential-based audit framework) tells you a protocol passed its evaluation in March; Attentra tells you whether the protocol's state in October still matches what STRIDE saw in March.

Other monitoring tools — Forta, Hypernative, Chaos Labs — do adjacent things, mostly off-chain and behind a commercial subscription. Attentra is on-chain, open methodology, and any program or wallet can compose against the signal without our permission.

The honest answer is that "true" means different things at different layers, and we verify each one differently. There are five layers in total. Three of them anyone can mechanically check, one we verify socially, and one we don't claim to answer at all. We're deliberate about not papering over which layer we're standing on.

The very short version: the score we published is provably the score we published (signature on Solana). The math is provably reproducible (open-source verifier — anyone can re-run it). The data we read is provably what was on chain (committed via fingerprints, full property landing before mainnet). Whether we're checking the right things is verified by transparency and being held publicly accountable, not by math. Whether the protocol is safe overall isn't our claim to make — that requires more inputs than we provide.

The verifier is a small program anyone can install and run from their laptop. Give it a Solana protocol, and it does the same calculation our engine did, against the same on-chain data, and tells you whether the answer matches what we published. If it matches, our work is reproducible. If it doesn't, we have a public problem to explain.

We license the verifier under MIT — the most permissive open-source license — specifically because the verifier is what makes our claims checkable. A verifier you couldn't freely use and inspect would defeat its own purpose.

Not silently — anyone running the verifier would catch it. Under today's design, that's true if you trust the verifier you downloaded uses the same code our engine uses (which we make easy to check by publishing all the source code). Before mainnet we close the gap further, by committing a fingerprint of the exact code that produced each score, so the verifier can confirm we used the methodology we say we used.

The bigger structural protection is that we publicly commit, in writing, to publishing a post-mortem within 24 hours of any confirmed divergence between what we published and what the verifier finds. So a quiet lie has a noisy half-life.

The on-chain design treats this as a foreseeable failure rather than a catastrophic one. If our signing key were stolen, an attacker could publish bad scores under our name during the period before detection. They could not redirect funds, modify the methodology, or change scores already published. And the verifier still works — anyone running it would see the divergence and know something is wrong.

The next version of the methodology adds multi-signature publishing, where two independent parties have to co-sign every score. That caps the worst case of a single-key compromise to "Attentra can't publish for a while" rather than "Attentra is publishing falsehoods." The full inventory of every component that could be compromised, and what that would mean, is in the threat model in the paper.

Eleven specific things. The configuration of the protocol's multisig (who the signers are, how many are required). Whether its program code or its upgrade authority has been changed. Whether its price oracles are reporting prices that diverge from independent reference sources. Its governance configuration and timelock duration. Whether dormant signer keys have suddenly come back to life. Whether protocol fees have been moved outside their declared safe ranges. Whether the treasury authority has been transferred to an unfamiliar key. And generic drift detection for anything else the protocol's declared baseline says shouldn't change.

Each of these eleven checks produces a result with a severity (Info, Low, Medium, High, Critical), and the score is a deterministic combination of those results. We use exactly the same arithmetic on every architecture, so the answer reproduces exactly.

Code-level vulnerabilities. If a protocol has a reentrancy bug or an integer overflow in its program logic, we won't catch that — code-level audits will. We watch the operational state around the code, not the code itself.

Economic attacks against mechanisms working as designed. A flash-loan price manipulation against a protocol whose oracle is doing exactly what it was designed to do is the protocol behaving correctly under hostile conditions. The fix is mechanism redesign, not monitoring.

Off-chain compromise. If a protocol team's email is hacked or their deployment infrastructure is breached, the attacker can execute on-chain operations that look indistinguishable from legitimate ones. We can only see what's on chain.

Novel attack patterns we haven't yet built a check for. Our current eleven checks cover the patterns we observed in the historical record through April 2026. New patterns produce new checks in future methodology versions, with public changelogs.

False alarms would destroy the system's value, so we built four layers of protection against them. First, every finding has a severity (Info through Critical), so consumers can set their own threshold rather than us forcing one. Second, when we detect a change, we hold it in a "pending review" status for a configurable window before treating it as confirmed — that catches transient or reorg-related noise. Third, the protocol team can sign an on-chain instruction acknowledging that a detected change is intentional (a planned signer rotation, for example), which marks the score with that context. Fourth, a separate watchdog process flags scores that have gone stale, so consumers know to ignore old data.

On top of that, we publicly commit during the first six months of mainnet operation to setting our severity thresholds at the conservative end of the defensible range. We'd rather miss a subtle finding than flag a healthy protocol incorrectly. As we accumulate operational evidence we can tighten thresholds, and we'll publish a changelog when we do.

They can file an on-chain dispute. Every protocol we monitor has a paired account where the protocol team can sign and publish a formal dispute record — pointing at the specific score they disagree with, citing the kind of disagreement (factual, methodological, or contextual), and linking to their own written explanation. The dispute becomes part of the permanent public record alongside our score.

The dispute doesn't change our score. The score is a function of on-chain data, not of opinions about it. But systems reading our score are expected to read the dispute too, and we publicly commit to a written response within 7 days. If the dispute reveals a real flaw in the methodology, we update the methodology and publish a changelog. If it doesn't, we explain why in writing — and the writing is the response, not a tweet.

The architectural intent here matters: a protocol team that disagrees with us has a productive, structured channel that puts their position into the public record. Going around the dispute mechanism to social media is observably less useful. We've made the legitimate response easier than the illegitimate one.

We will. It's a question of when and how we handle it. Our public commitment is to publish a post-mortem within 24 hours of any confirmed mistake — whether the mistake is detected by a verifier disagreement, raised in a sustained dispute, or surfaced by an independent forensic analyst. The post-mortem identifies the affected score, what went wrong, the corrected score, and what we changed in the methodology to prevent the same thing happening again.

We treat this like an airline treats incident reports — boring documents, published reliably, not a defensive exercise. The legitimacy of the system depends on us being more honest about our errors than anyone else would be on our behalf.

Three channels, depending on the kind of report.

Verifier disagreements on a published score: email verify@attentra.xyz with the program ID, the score's published slot, and the verifier's output. We confirm within 24 hours and, if confirmed, publish a post-mortem within another 24.

Methodology critiques — disagreements about what we should be checking, how findings should be weighted, where the methodology has gaps: file an on-chain dispute if you're a monitored protocol, or email methodology@attentra.xyz. We respond in writing within 7 days.

Security issues in the on-chain program, the off-chain engine, the verifier, or any infrastructure: email security@attentra.xyz. We follow standard coordinated disclosure.

The on-chain part runs on Solana — devnet today, mainnet scheduled for Q3 2026 after external audit. The off-chain engine that produces scores is operated by Attentra Labs, connected to Solana via standard streaming infrastructure, publishing scores to chain on a regular cadence.

The verifier, importantly, runs anywhere — it's just a binary you install. It needs only a Solana RPC endpoint, not anything we operate. So even if our engine went away, the scores already on-chain would remain verifiable.

The system is designed so that an engine outage produces a quiet failure rather than a noisy lie. A separate watchdog process watches each score's freshness; if a score gets too old without an update, the watchdog marks it as Stale, and consumers know to fall back to whatever default they have.

So a failed engine is a denial-of-service (no fresh signal) rather than a correctness failure (no false signal). We treat sustained outages as P0 incidents with public status reporting.

Two kinds of audit. First, the on-chain Anchor program goes through external audit before mainnet launch — Asymmetric Research, OtterSec, and Neodyme are on the shortlist. Audit reports will be published alongside resolutions.

Second, the methodology itself is audited socially — through the dispute mechanism, the post-mortem commitment, and our commitment to soliciting an independent verifier implementation, in a different language, by someone other than us, within twelve months of mainnet. The day two independent verifiers in two languages produce identical answers across a large sample of scores is the day our verification claim becomes very hard to attack.

Two sides. Protocols can subscribe to receive early alerts when our system detects a change to their state, to participate in the override-acknowledgment process, and to access tier-specific configurations of our checks. Three tiers, priced in USDT, settled on-chain. An Enterprise tier for custodians and exchanges is handled off-chain.

On the consumption side, underwriters, lending markets, risk engines, and others who use scores as inputs to their own decisions can subscribe for higher-fidelity feeds, real-time alert streams, and access to historical query data.

The important thing: we monitor any deployed Solana protocol whether or not they pay us. The on-chain data is public; our methodology applies to it; our scores reflect that data. What's optional is whether a protocol participates in the surface around the score — declaring a baseline, acknowledging changes, filing disputes. Coverage isn't opt-in. Participation is.

The verifier is MIT-licensed — the most permissive license, deliberately chosen because the verifier is the instrument through which our claims are checked. A verifier under commercial license would defeat the point.

The methodology paper is freely readable and citable. The on-chain Anchor program and the off-chain engine are licensed under BUSL 1.1 — source-available for inspection and self-deployment, with commercial use under license, and automatic conversion to Apache 2.0 four years after release.