Resolv vs Kerne.

What happened to Resolv on March 22, 2026.

Resolv's normal USR mint flow ran like this. A user sent USDC to a contract entry point. An off-chain Resolv backend observed the deposit, computed the USR amount, signed an instruction with a backend-held key (the SERVICE_ROLE in their AWS KMS configuration), and called completeSwap on the on-chain contract. completeSwap accepted the instruction if the signature matched the configured SERVICE_ROLE address, and minted the requested amount of USR to the user.

The exploit. An attacker compromised the SERVICE_ROLE signing key. They sent $100,000 of USDC into the deposit entry. They then signed and submitted a completeSwap instruction calling for 80 million USR against that deposit. The on-chain contract verified the signature, observed it matched the configured SERVICE_ROLE, and minted. There was no on-chain check that the requested mint amount was bounded by the deposit. There was no per-block, per-day, or per-call cap. There was no second signer requirement. The off-chain key was sufficient.

That is the entire exploit, end to end. The $24.5 million extracted afterward was the attacker swapping the unbacked USR through Resolv's secondary markets before the team could pause the contracts. For the full forensic walkthrough, see the post-mortems linked at the bottom of this page.

The class of failure, not the specific bug.

The architectural class of failure here is not "Resolv had a bad key-management process." Plenty of protocols have had keys compromised. The class of failure is: a single off-chain key was the sole gate on an unbounded on-chain state change.

Three properties combined to make the Resolv vector exploitable.

1. The on-chain mint amount was set by the off-chain caller, not derived from on-chain state. The contract did not verify the relationship between USDC deposited and USR minted; it took the requested amount as authoritative.
2. There was no per-call or per-block ceiling on the mint quantity. A single transaction could mint any number, including amounts orders of magnitude larger than the protocol's total backing.
3. The privileged role required exactly one signature, and the signer was an automated off-chain process whose key lived in a cloud KMS rather than in cold-stored multisig hardware.

Any one of these three would have been recoverable. Two of them combined would have been damaging but bounded. All three together made the protocol's entire collateral pool extractable in seventeen minutes by anyone who got the one key.

This is not a Resolv-specific failure mode. Several active synthetic-dollar protocols ship with at least one of the three properties present. Two of them is more common than the public discourse suggests. The longer companion essay at /insights/resolv-exploit-synthetic-dollar-mint-paths walks the three questions you can ask of any synthetic dollar before depositing.

How Kerne's mint path differs.

Authority. AccessControl with two named roles: DEFAULT_ADMIN_ROLE and MINTER_ROLE. DEFAULT_ADMIN_ROLE is held by a 2-of-3 Gnosis Safe multisig at 0x52d3E450bA6c299B1B07298F1E87DD74732D4877. MINTER_ROLE is held by exactly two contracts: KerneVault at 0x8005bc7A86AD904C20fd62788ABED7546c1cF2AC and KUSDPSM at 0xFf3025ec18e301855aB0f36Ec6ECa115a29A5Fbc. Both are on-chain contracts. No off-chain key holds the mint privilege.

Mint amount. The user-facing mint path is KUSDPSM.swapStableForKUSD. It reads the USDC the user deposited from the contract's own balance, applies a 10 basis point fee defined as a contract constant, and mints the resulting kUSD. There is no caller-supplied mint quantity, no off-chain "this is what you are getting" signal, no SERVICE_ROLE equivalent. The function is a pure on-chain calculation.

Caps. KUSDPSM enforces an on-chain mintingEnabled flag that the multisig can flip in one transaction if anything looks off. The Phase 2 kUSDMinter contract, in source but not yet deployed, additionally caps mint at a configurable per-day amount as a defense-in-depth ceiling. For Genesis Window scale this is intentionally conservative.

These three are checkable in three commands against Base mainnet.

The same three checks run in continuous integration hourly via .github/workflows/onchain-role-smoke.yml and are surfaced as JSON at /api/risk-status, with a human-readable rendering at /risk. If any value flips, the workflow fails and the homepage banner reflects it.

Quick comparison.

Snapshot as of May 19, 2026. Both protocols evolve; verify current values at the canonical sites linked in each row.

What Kerne still owes.

This page is not a claim that Kerne has nothing left to harden. The internal adversarial audit run on May 8, 2026 catalogues 201 findings across the full contract set: 36 rated critical, 51 high, 51 medium, 37 low, 26 informational. The Phase 2 kUSDMinter contract referenced above is in source but not yet deployed. The KerneVerificationNode for cross-chain attestation is also in source and not yet deployed. The current WETH vault at 0x8005bc7A86AD904C20fd62788ABED7546c1cF2AC is in a degraded accounting state that is ringfenced via the mintingEnabled flag plus the live vaultDegraded field on /api/stats; the vault refactor and redeploy are on the punch list. Several access-control hardening items from the audit's section on default thresholds, role-admin self-loops, and single-key STRATEGIST_ROLE on adapter contracts remain on the remediation queue.

The point of this page is a posture difference, not an immunity claim. Every claim about how Kerne's mint path works is verifiable in three commands. Every gap is named with the remediation status visible at /security/audits and /security/findings-tracker. The Resolv exploit was a class of failure that would have been detectable to any reader running the three questions in the companion essay against any synthetic dollar beforehand. The protocols that survive long-term will be the ones whose readers do.

If you were holding USR.

For questions about Resolv's current state, redemption status, or any USR holdings, the canonical source is resolv.xyz and the Resolv team's public communications. This page does not provide guidance on Resolv-side actions.

If after reading the post-mortems and this page you are evaluating Kerne as one of several synthetic-dollar options, the four most useful surfaces are below. Each is a live link, not a marketing claim.

• /api/risk-status: every wired risk threshold with its current on-chain value and source-file attribution.
• /api/por/signed: hourly EOA-signed Proof of Reserves JSON with on-chain WETH, off-chain hedge equity, solvency ratio, and signature.
• /insights/resolv-exploit-synthetic-dollar-mint-paths: the longer companion essay walking the three questions to ask of any synthetic-dollar mint path before depositing.
• /security/audits: every internal audit finding by severity, with status and commit reference if resolved.

Next steps on Kerne.

You just saw how to verify Kerne from the outside. The next step is to hold the dollar you can check for yourself.