Live on Aurora testnet + Base Sepolia

Exploits revert.
Everything else goes through.

Kronos is a security layer for lending protocols. AI in a hardware enclave on NEAR AI Cloud drafts the guard. Aurora enforces it on every transaction. A NEAR key that can only tighten handles emergencies on every chain.

The AI drafts. Your team approves every rule
You merge the guard as one pull request
Testnet today: Aurora, Base Sepolia, NEAR

attack replays stopped on a fork: 6/6attack replays stopped on a fork
Foundry tests in the guard suite: 28Foundry tests in the guard suite
on-chain checks before a guard goes live: 30/30on-chain checks before a guard goes live
on NEAR, tighten-only, for every chain: 1 keyon NEAR, tighten-only, for every chain

01How it works

Three layers. NEAR does the work in each one.

An enclave to write the rules, a cheap chain to enforce them, and a key that cannot make things less safe to respond when something goes wrong.

1Analyze
Two AI models draft your rules inside a hardware enclave.
- Two independent models write the invariants
- Where they disagree, the decision comes to you
- You approve every rule before anything ships
runs on NEAR AI Cloud
2Enforce
The guard checks every transaction on-chain, for fractions of a cent.
- Guard checks run on Aurora testnet, and on Base Sepolia
- Every action is checked against your invariants
- Risky admin changes wait 2 to 14 days in public
runs on Aurora, NEAR’s EVM
3Respond
One NEAR key handles emergencies on every chain. It can only tighten.
- The key is limited on NEAR to one method: tighten
- The registry builds the EVM transaction itself
- NEAR’s MPC network signs it. We never hold an EVM key
runs on NEAR Chain Signatures

The only-tightens rule

Our monitor can only make your protocol safer.

Its NEAR key is limited to one action: tighten. Three separate layers refuse anything else, so a stolen key or a confused agent still cannot raise a limit or move funds.

01NEAR rejects any method other than tighten for this key.
02The registry only signs transactions it built itself: an outflow tighten, to your registered guard.
03The guard reverts anything that is not tighter than before.

Same key, two requests

tighten(outflow)signed

200,000 → 100,000 · signed by NEAR MPC · sent to the guard on Aurora testnet

loosen(outflow)refused

100,000 → 200,000 · NotTighter

Chain Signatures covers outflow tightens today, on Aurora testnet and Base Sepolia. Why NEAR

02Attack ledger

Six attack patterns from 2026. None of them moved funds.

Each one is modeled on a real incident and replayed on an anvil fork of the MiniLend sample. The verdicts come from the fork tests, and every row links to its test.

01
Oracle pump
Spot price pushed 41% above the attested TWAP, then borrowed against.
modeled onthin-collateral oracle pumps
blockedcheckOracle
02
Share inflation
A donation moves the exchange rate inside a single transaction.
modeled onrounding / donation attacks
blockedcheckSharePrice
03
Fake collateral listing
A new market is listed and borrowed against immediately.
modeled onfake-collateral listings
blockedprobation + Tier 2 timelock
04
Timelock bypass
Governance tries to skip the delay on a risk-adding change.
modeled onadmin oracle swaps
blockedguard-owned timelock
05
Split withdrawals
25 same-sized outflows, each one under the per-transaction cap.
modeled onrolling-window drains
queuedoutflow window
06
Intent tampering
Calldata amount differs from the signed EIP-712 intent.
modeled onsignature replay
blockedintent pre-check

03Onboarding

From a pasted repo to a live guard in four steps.

AI drafts the rules. Fork tests prove them. Your team signs off. The AI never decides alone: models agreeing with each other counts for nothing, and the compiler has the last word.

Paste the GitHub repo. The code is the source of truth; your website only adds hints, like deployed addresses.

/connect

websitehttps://minilend.xyz

repogithub.com/minilend/protocol

chainAurora testnet

detected MiniLend.sol, MiniLendCore.sol · 2 addresses from deploy files

04The guard

One modifier, two doors. Nobody skips the checks.

Users arrive with a signed intent. Admins arrive through the timelock. Both hit the same five stages, and the guard judges the resulting state, not the size of the transaction.

Door 1

Users

signed EIP-712 intent

guarded(kind, intent, sig)

Door 2

Admins

timelock, tier 0 to 3

onlyTimelock → same guard

- EIP-712 signature from the account
- Nonce unused, deadline not passed
- Calldata within signed bounds (amount, max LTV, min health, recipient)

05Admin keys

Safer is instant. Riskier has to wait.

Admins change settings and never move funds. Tightening applies immediately. Risky changes wait 2 to 14 days in public. Guardians can cancel, never execute.

Tier 0

Instant

Pause, lower caps. Tightening never waits.

Tier 1

48 hours

Routine parameter changes.

Tier 2

demo below

7 days

New collateral, oracle changes.

Tier 3

14 days + co-sign

Upgrades, guard and key changes.

Public waiting queue · 1 pendingday 2.5

tier 2 · queuedlistCollateral(FAKE, ownOracle, 75%)

executes in 4.5 days · proposer 0x6b11…c3e2

Guardians can cancel a queued action. Nobody, guardians included, can execute one early.

06Coverage

What it stops, and what it doesn’t.

A guard is one layer. Here is exactly where this one ends, so you know what still needs an audit.

Share of 2026 losses in scope

≈98%

of named smart-contract hack dollars, March to November 2026. About $140M across 13 incidents.

stops

Oracle manipulation
Accounting bugs: share inflation, rounding, insolvency
Unsafe admin changes, including from your own keys
Drains through old approvals
Split withdrawals under a per-transaction cap (queued)

doesn’t stop

Phishing: a user signing a malicious intent
Exchange or wallet key theft
Chain-level bugs
Bugs in the invariants themselves

Keep audits and fork tests in your release process.

07Protocol types

Lending ships first. The same guard model carries to the rest.

Not a lending protocol? Paste the repo anyway. We classify it and put you on the waitlist for your type.

Lendinglive MVPCompound- and Aave-style markets: health, solvency, share price, oracle, caps.
BridgesnextMint/lock parity, message replay, relayer key changes.
DEXs and perpslaterPool invariants, funding and mark-price sanity.
Vaults and restakinglaterShare price, withdrawal queues, operator changes.

08Integration

A modifier, four lines of SDK, one deploy command.

01ContractsWrap each entry point in one modifier. Your function bodies run unchanged.
02FrontendBuild and sign the intent with the SDK. Exact-amount approvals only.
03DeployRun the generated forge script, paste the guard address, go live when every check passes.

import {KronosGuard} from "@kronos/contracts/KronosGuard.sol";

contract GuardedMiniLend is MiniLend, KronosGuard, GuardConfigMiniLend {
    function borrow(Intent calldata intent, bytes calldata sig)
        external
        guarded(Kind.Borrow, intent, sig)   // pre-checks → body → post-checks
    {
        _borrow(intent.account, intent.asset, intent.amount);
    }
}

Start here

Paste the repo. Watch the red team work.

You get a live log of every entry point mapped, every invariant drafted and every attack replayed. Nothing ships until your team approves every rule.

Exploits revert. Everything else goes through.

Two AI models draft your rules inside a hardware enclave.

The guard checks every transaction on-chain, for fractions of a cent.

One NEAR key handles emergencies on every chain. It can only tighten.

Paste the repo. Watch the red team work.

Exploits revert.
Everything else goes through.