Wave 2 checklist

Each point of the Wave 1 judge feedback, with its status and the evidence behind it. Statuses:

• Done and proven: shown on Mezo testnet or on the live site, with links.
• Done, not yet proven on-chain: built and tested, but the on-chain run is still outstanding.
• Not done: with the reason.

Commit links point to github.com/Im-2/keel.

#1. A web link without Telegram: done and proven

Limitation: alerts are Telegram messages. A web-only account must use Connect Telegram to receive them.

#2. Partial rescue instead of revert

#2a. What Mezo allows (read from the MUSD source)

In BorrowerOperations._adjustTrove:

• Normal Mode requires the resulting ICR to be at least 110% (and TCR at least 150%) for any adjustment.
• Recovery Mode allows a pure top-up and/or repayment at any ratio.
• A repayment must also leave net debt at or above minNetDebt.

So a top-up that can't lift a loan back over 110% is rejected by Mezo itself, not by Keel.

#2b. The change: done

KeelGuardianV2.protect() returns a Result:

• Full (0) and Partial (1): funds move. Partial adds PartialRescue(…, btcShortfall).
• Insufficient (2): when nothing Mezo would accept is affordable, it moves nothing, pays no tip, leaves the cooldown free, doesn't revert, and emits InsufficientReserve(icr, btcShortfallToMCR, btcShortfallToTarget, recoveryMode).

BTC and MUSD are applied in one adjustTrove. previewProtect() returns the plan without sending anything. See Guardian protection.

#2c. Proven in tests against the real MUSD stack: done

contracts/test/keel/KeelGuardianV2.test.ts, 17 passing (41 Keel contract tests in total):

• factory v2 clones a V2 implementation deterministically, once per owner;
• hard-caps the protocol share at 50% of the tip, and only the admin can change it;
• transfers admin in two steps;
• full rescue: restores the target and pays the keeper its tip minus the treasury's 20% share;
• pays no protocol share when the treasury is unset;
• partial rescue: applies the whole reserve, emits PartialRescue with the exact shortfall, and the shortfall really completes it;
• combines BTC and MUSD in one adjustment when BTC alone would leave the loan under 110%;
• impossible rescue (Normal Mode, below 110%): moves nothing, pays no tip, keeps the cooldown free, and reports the BTC needed to clear 110%. The same test shows Mezo itself rejecting the sub-110% top-up;
• respects MUSD's minimum net debt: a minimum-size loan can only be repaid down to the minimum;
• Recovery Mode: allows a partial top-up even if the loan stays under 110%;
• treats a dust reserve as nothing to do (no revert, no tip);
• an insufficient result can repeat (no cooldown); a rescue can't (cooldown applies);
• at the maximum (1% tip, 50% share) the owner pays exactly 1% of what was applied;
• a keeper contract can't re-enter protect() through its tip;
• only the owner controls funds and settings;
• it still reverts when not eligible: disabled, no trove, healthy;
• KeelPro takes MUSD straight to the treasury, stacks time, and caps the price.

The bot side is also tested: the "reserve can't fully protect your loan" and "your guardian can't act yet" alerts (with the exact BTC plus 2%), and the partial-rescue notice (bot/test/alerts-keeper-api.test.ts).

#2d. v2 on Mezo testnet: done and proven (full, partial, insufficient)

Deployed and verified (deploy transactions):

• KeelGuardianFactoryV2: 0x98faa485…
• KeelPay v2: 0xdfcd666f…
• KeelPro: 0x5bd17e59…

The run: bot/scripts/guardian-v2-testnet.ts, with a fresh wallet 0xf44c91FF…3001 (a team test wallet, so /stats doesn't count it as a user). It went through the production code paths:

• The loan, reserve and settings use the Mini App's own transaction plans.
• protect() is signed by the production keeper wallet's key (the script calls it directly, the same transaction the running keeper sends; the running keeper process itself did not make these calls).
• The "add X BTC" message comes from the bot's real alert engine reading the real chain.

The guardian is 0xE7f4B337…B3D6, a KeelGuardianV2 clone made by factory v2, with a loan of 1,800 MUSD (BTC at $64,230 on Mezo's oracle).

The owner is told how much to add (the bot's real alert engine reading this loan after step (c)):

🚨 Your guardian can't act yet. Your ratio is 150%, under your 165% trigger, and the reserve (0 BTC) is too small for a top-up Mezo would accept. Add 0.00795 BTC to the reserve and the next keeper check rescues it.

The BTC figure is the reported shortfall plus 2%, rounded up. The alert's own code path (message plus a one-tap fund-reserve button) is covered by bot/test/alerts-keeper-api.test.ts.

The first protocol revenue: the two rescues paid 0.0000008 BTC to the treasury through ProtocolFeePaid, exactly 20% of each keeper tip (tip 0.2% of the amount applied). It's tiny, because this is a test with a few thousandths of a BTC, but it shows the on-chain split working.

On /stats (tick "include the Keel team's own and test wallets"): all three runs appear, with the ratio before and after, and the revenue panel shows the protocol fees.

What this does not show. The Insufficient run happened above 110%, because the wallet could afford only a loan at 150%. It proves the no-revert path, the event and the shortfall, but not the sub-110% case where Mezo would reject a top-up. That case is proven in the contract tests (which show Mezo rejecting the sub-110% top-up), because forcing a real loan below 110% on a shared testnet means moving the oracle price.

#2e. What testnet already shows (v1): proven

v1 guardians on testnet, read on-chain by /stats. All four are team wallets:

The two price-triggered protections were real market moves, and they were partial because those reserves were nearly empty. That is exactly the case v2 now reports explicitly, with the BTC to add (see 2d for the v2 runs).

#3. Verified sources on the Mezo explorer: done and proven (7 of 7)

Each page shows "Contract source code verified (exact match)": solc 0.8.24+commit.e11b9ed9, optimizer on with 100 runs, EVM london, GPL-3.0. Each was confirmed through the explorer API (is_verified: true).

How: contracts/scripts/verify-blockscout.py, which submits the standard-JSON input to Blockscout's verification API. Commit 297535e.

#4. A firmer revenue model: done

• On-chain today: a protocol share of every keeper tip goes to the treasury.

  • It is 20% now, hard-capped at 50% in both KeelGuardianFactoryV2 and KeelGuardianV2.
  • The owner never pays more than the tip, which is itself capped at 1%.
  • Every payment is a ProtocolFeePaid event, shown in the /stats revenue panel.
  • Collected so far: 0.0000008 BTC, from the two v2 rescues in 2d (20% of each tip). It's tiny because it's a test.

• KeelPro subscription contract: deployed and verified. It pays MUSD straight to the treasury and the price is hard-capped. The Pro features in the app aren't built yet.

• Documented: Business model covers:

  • target users;
  • market sizing with stated assumptions;
  • unit economics and a sensitivity table;
  • five streams: tip share, Pro, merchant checkout at 0.3–0.5% (P2P stays free), team and DAO plans, and Guardian API licensing.

  It is on slide 10 of the deck.

• Commits: 8c91e7f · 77d887b.

#5. A pitch deck: done

• 12 slides: problem, solution, live screenshots, architecture, the Mezo/MUSD integration (contracts and functions), the Guardian and keeper explained visually, payments, traction (real numbers from /api/stats), business model, roadmap, team.
• Where: PDF · PPTX, also in submission/ and docs/keel-deck.pdf.
• Source: submission/deck/ (deck.html, build.mjs, build-pptx.py). Commit d20601b.

#6. Real third-party users and price-triggered protections: tracking ready; users not there yet

• /stats reads everything on-chain:

  • guardians on every factory;
  • owners and open loans;
  • every protection, with the BTC price at that block, the ratio before and after, and whether a price move or the owner's own change triggered it;
  • revenue.

  Team and test wallets (listed in shared/deployments/testnet.json → teamWallets, plus the keeper and treasury) are excluded by default, with a toggle to include them.

• Today: 0 guardians from outside the team. All 3 guardians, all 7 recorded protection attempts (4 v1, 3 v2) and the v2 test wallet belong to the team.

• For testers:

  • the web app and demo mode remove the Telegram requirement;
  • Set to test on the Protection screen puts the trigger one point under the current ratio, so a real oracle dip triggers the keeper;
  • Quick start walks through it.

• Recruiting testers is the team's job and isn't done yet.