DEV Community: Pugar Huda Mantoro

Invoice Chaser: an invoice tool that learns how each client pays (Walrus Memory + Tatum on Sui)

Pugar Huda Mantoro — Wed, 04 Nov 2026 00:54:30 +0000

Every freelancer has a client like Acme. The invoice is due on the 5th, nothing happens, you send a friendly nudge on the 6th, nothing happens, and somewhere around the 10th the money shows up, usually right after you finally write something formal. Next month it happens again, because your invoicing tool has no idea it already happened four times.

I built Invoice Chaser for the Total Recall hackathon (Tatum × Walrus Memory) to fix exactly that. It's an invoice tracker for freelancers who get paid in USDC on Sui, and it remembers how each client pays.

Live demo: https://invoice-chaser-sigma.vercel.app
Video (2:08): https://youtu.be/nCpQtlcQF-0
Code: https://github.com/PugarHuda/invoice-chaser

What it does

You issue an invoice. Instead of "300 USDC" the client is asked to pay something like 300.004217 USDC. Those extra micro-decimals are the invoice's fingerprint on-chain.
The client opens a pay link with a real sui:pay QR code and pays from any Sui wallet. The payment goes through the Sui Payment Kit registry with the invoice as the nonce, so the chain refuses a second payment for the same invoice, and the app finds the payment by invoice on its own. Every payment is checked on Sui Mainnet through Tatum's gRPC gateway: did it succeed, how much USDC landed on my address, is it newer than the invoice, has this transaction been used before, and which wallet paid.
Everything that happens (invoice sent, reminder sent and in what tone, paid how many days late, underpaid by how much, and any rule you tell it) is written to Walrus Memory.
Before the next reminder, the app recalls that client's history and decides when to chase, in what tone, and what it expects to happen. A "Why?" panel shows the memories behind each decision.

The part judges asked for: does it actually learn?

Here is the same invoice for Acme (due 5 Nov) with memory switched off and on:

	Memory off	Memory on
First reminder	6 Nov, friendly	9 Nov, formal
Predicted payment	—	10 Nov
Why	default schedule	Acme paid +4, +6, +5, +5 days late; formal reminders were followed by payment within 3 days 4/4 times, friendly 1/3

And the prediction got better with each invoice it saw. Before each of Acme's last four payments the app predicted how late it would be. It was off by 4 days, then 2, then 0, then 0. That chart is in the app, on every client page.

Rules work the same way. Type "never chase Acme before the 10th" into the client page and it becomes a memory; the next plan moves the reminder to the 10th, and the Why panel says so. Or paste the client's email: Walrus Memory's analyze() pulls out "vendor payments are only run on Thursdays and never before the 15th" as a fact, and the plan predicts a Thursday payment and holds reminders until the 15th, even for a client with no payment history yet. (My first parser read that sentence as "don't remind on Thursdays". A Playwright QA pass caught it.)

How it uses Walrus Memory

I didn't want memory to be a log on the side, so Walrus Memory is the only database.

Every event is one memory: a sentence a human can read, plus a small JSON tag the code can parse:

Acme Corp paid inv-095 in full (3500.007537 USDC) on 2026-10-20, 5 day(s) after due, after 1 reminder(s); last tone formal.
#ic {"type":"invoice_paid","client":"c1","invoice":"inv-095","delay_days":5,"reminders":1,"last_tone":"formal",...}

Each client gets its own namespace (ic:main:client:<id>). When the server starts it holds nothing. It lists the namespaces, recalls each one, and rebuilds clients, invoices and learned profiles from Walrus. There's a Total Recall button that throws away local state and does it again on demand. This also happens to be the only way to run on the Tatum AI Builder preview, which has no database at all.

Two practical things I learned:

A Mainnet write takes ~25 seconds end to end (encrypt, embed, store, certify). So writes go into a background queue; the UI says writing to Walrus… until the relayer confirms, then links the blob on Walruscan. Nothing is ever shown as saved before it is.
recall is similarity-ranked and capped at 100, so it's not an inventory. I use listNamespaces to know how many memories should exist, and if a recall comes back short the app refuses to settle payments rather than risk accepting a digest it can't see was already used.

The demo history (Aug–Oct, 38 memories) was written with a seed script that uses the app's own format. Every seeded memory carries "seed": true and the UI labels it. Anything you do in the app is a real new memory.

How it uses Tatum

All chain reads go through Tatum's Sui Mainnet gRPC gateway (sui-mainnet-grpc.gateway.tatum.io, x-api-key header), with SuiGrpcClient from @mysten/sui over native gRPC:

LedgerService.GetTransaction: verify a payment from effects.status and balance_changes
StateService.GetBalance: watch the payee's USDC balance
LedgerService.GetCheckpoint: the live proof page
building the payer's Payment Kit transaction (coin selection, gas) and executing an agent's signed payment
looking an invoice's payment up in the Payment Kit registry, and the payer's SuiNS name

Sui's JSON-RPC was deprecated during the hackathon, and gRPC has no "list transactions for an address" call. The Sui Payment Kit fixed that for me: a payment is a record keyed by the invoice, so I look it up directly instead of scanning history. (One gotcha: the SDK's getPaymentRecord builds a malformed type name, PaymentKey<phantom T><coin>, so I query the dynamic field myself.) The free plan allows 3 requests per second, so calls are throttled and 429s are retried with backoff.

Agents can pay too (x402)

Every invoice is also an HTTP resource. An accounts-payable agent that requests it gets 402 Payment Required with the terms (USDC on Sui, amount, payee, and the Payment Kit registry + nonce), pays, and retries with X-PAYMENT: <digest> to get a receipt. The repo has a reference agent that checks its own budget before paying.

Tested on testnet first

The same code runs against Sui Testnet with one env var (Tatum's testnet gateway, Circle testnet USDC, testnet Payment Kit) and a separate memory namespace. An end-to-end script pays a real invoice as an x402 agent, then checks on-chain that a second payment is rejected, that an unreported payment is found and settled automatically, and that a replayed transaction is refused. All six checks pass.

Then on Mainnet

On Sui Mainnet, an agent asked for invoice inv-mvzyioev, got 402 Payment Required, noticed it held no USDC, swapped just enough SUI through the Cetus aggregator, paid through the Payment Kit registry and got its receipt (payment). A second invoice was paid through the registry and nobody told the app; the production server found it by invoice nonce and settled it (payment). Delta Studio, a client with no history that morning, now has two remembered on-time payments, and its profile changed accordingly.

And over MPP

The same invoice is also a Machine Payments Protocol charge (/api/chaser/mpp/<invoice>, built on @suimpp/mpp). An agent got the WWW-Authenticate: Payment challenge, paid 0.015645 USDC and received a Payment-Receipt (payment); the server verified it again through Tatum before remembering it.

No SUI needed, and no waiting

Clients shouldn't need a second token just to pay gas. The pay page now builds the Payment Kit transaction with the server's wallet as gas owner: the payer signs, the server adds its signature and submits. And an open pay page listens to Tatum's gRPC checkpoint stream, so it flips to paid the moment the money lands. One Mainnet payment shows both: the payer's SUI balance didn't move, and the stream caught it at checkpoint 341405407 (payment).

Agents can read the memory too (MCP)

The app is also an MCP server. claude mcp add --transport http invoice-chaser https://invoice-chaser-sigma.vercel.app/api/chaser/mcp gives Claude 12 tools, like client_profile, plan_reminder, chase_queue and search_client_memory, over the same Walrus memories.

A statement you can send to the client

Each client has a statement of account (JSON or CSV, and the client_statement MCP tool): every invoice and payment from Walrus Memory, with each payment re-checked on Sui in one Tatum BatchGetTransactions call and linked to its explorer page and the Walrus blob that remembers it. For the client with real Mainnet payments, all 7 come back verified on Sui.

Receipts that outlive the app

When an invoice is paid, the app can render a PDF receipt and store it on Walrus as a blob for a year, then remember the blob id in the client's memory. The payer gets the same link on their pay page. Here is one from Mainnet. The UI itself is also published as a Walrus Site.

Starting with Tatum AI Builder

The first version came from one prompt in Tatum AI Builder (the prompt is in the repo, the generated commit is tagged ai-builder-v0). It produced a clean UI with all five screens and a sensible profile algorithm. The backend was a mock: in-memory data, fake memories, a simulated wallet payment, and a QR code that was just an icon. I kept the UI and replaced every mock with the real thing: Tatum gRPC, Walrus Memory, Sui Payment Kit, and a payment check that can say no.

Limits I know about

Reminders open in your email app with the pay link; the app does not send email itself.
Rules are read with a small parser (day of month, pay days, days to avoid, tone). Stranger phrasing ("after their board meets on the first Tuesday") isn't understood yet.

Thanks to the Tatum and Walrus teams for the quick answers in Discord.

TotalRecall @tatum_io @WalrusProtocol

I let Stripe grade my tests: building a billing simulator where no expected value comes from my own code

Pugar Huda Mantoro — Thu, 22 Oct 2026 05:12:30 +0000

Built for the TestSprite Hackathon, Season 4. Live: tera-orpin-three.vercel.app · Code: github.com/PugarHuda/tera

Founders are afraid to touch pricing, and they are right to be. Move a customer from $29 to $79 on day 17 of a 31-day month and Stripe writes two proration lines you have probably never computed by hand: an "Unused time" credit of −$14.03 and a "Remaining time" charge of $38.23, on top of the $79 renewal. Add a coupon that was applied once, a tax rate that is inclusive, a trial, or a subscription in Stripe's new flexible billing mode, and the invoice your customer sees is no longer something you can predict from the pricing page.

Tera simulates it first. You give it a customer timeline (subscribe, change seats, upgrade, apply a coupon, pause, cancel) and it returns every invoice to the cent, plus the webhook events Stripe will send for it. This post is not really about the simulator, though. It is about the question every test suite eventually has to answer: who decides what the right answer is?

The rule: the engine never writes its own expectations

The easiest way to get a green test suite for a billing engine is to run the engine, save its output, and assert that it does not change. That suite is worthless the day the engine is wrong, because it was wrong when the snapshot was taken too.

So Tera has one rule. Every expected value is derived by hand from the billing rules, written next to its arithmetic, and then replayed in a real Stripe test-mode account with test clocks. Scenario S05 in golden/scenarios.json looks like this:

"math": "remaining 15/31: -round(2900*15/31)=-1403, +round(7900*15/31)=3823",
"expect": [{ "date": "2027-02-01", "lines": [-1403, 3823, 7900], "total": 10320 }]

A script creates the same customer in Stripe, advances a test clock through the timeline, reads back Stripe's invoices and diffs them line by line against both the hand-derived values and Tera's engine. Only when all three agree is the scenario marked verified, and the evidence (invoice ids, test clock id) is committed to the repo. Today there are 138 golden scenarios and all 135 timelines among them match Stripe to the cent. The other three are migration scenarios with no invoices to replay.

When Stripe disagreed with my hand derivation, Stripe won, and I kept the receipts. A coupon applied in the same second as subscribing discounts the next invoice, because Stripe finalizes the first one at creation. A repeating coupon for 3 months lasts three calendar months, not three invoices. A percent discount on a proration comes off the rounded gross. None of those were in my head when I started.

Letting Stripe find the cases I did not think of

Hand-written scenarios only cover what you already suspect. So Tera also runs differential fuzzing: a seeded generator produces random customer timelines, with month-end anchors, Feb 29, random times of day, trials, seat and plan changes, coupons and both tax behaviours. Each one runs through Tera and through Stripe, and any difference is a finding.

Every finding goes through the same pipeline: a targeted Stripe probe to isolate the rule, a new hand-derived golden scenario that pins it, then the engine fix. The fuzzer runs nightly in CI with fresh seeds, in both of Stripe's billing modes. The rules it surfaced are some of the most interesting in the repo. Stripe prorates the unit price to 12 decimals before multiplying by seats, so a credit of exactly 11257.5 lands a cent under the tie. In flexible mode every credit refunds its original debit with the gross and the discount rounded separately.

This week the same approach caught a real gap in usage-based billing. A code audit found the engine silently dropping metered usage on an immediate cancellation. Seven live probes gave the rules: tier lines run only up to the tier the usage reaches, a metered item has no unused-time line, and cancelling with invoice_now bills the usage so far. A follow-up fuzz batch for metered prices then found that Stripe still sends a $0 final invoice after an unused last period. It also found a stale usage window in my own replay script.

Where TestSprite fits

Stripe is the oracle for the engine. TestSprite is the gate for everything a user actually touches.

28 UI tests on every pull request, run by the TestSprite GitHub App against that PR's own Vercel preview. Branch protection requires the TestSprite V3 check. Each test asserts hand-derived amounts in the browser: "Invoice 2 totals $103.20", not "an invoice is shown".
The tests live in the repo. Every plan is a JSON file in testsprite/plans/ and every test has hand-written Playwright code in testsprite/code/. A CI check compares both with the cloud project and fails on drift. That matters because an auto-healing run can quietly rewrite stored code, for example pinning a preview URL or loosening an assertion to two words.
API tests against the preview, too. TestSprite gives backend tests no target URL, so a small script stores each API test with its base URL pointing at the PR's preview, runs it with auto-heal off, and puts production back.
Triage that uses the oracle. When TestSprite V3 fails, a workflow downloads the failure bundle, replays the golden scenarios behind that test on the same preview, and compares them with Stripe's recorded invoices. One PR comment then says either "engine still matches Stripe, so this is a UI regression" or which invoice the engine now gets wrong.
A nightly money-math canary on production, plus Playwright user journeys, Schemathesis fuzzing of the OpenAPI spec, Arazzo workflows, Lighthouse budgets and Stryker mutation testing on every PR.

TestSprite caught a real bug before merge on PR #18. A price added in the builder billed $0.00 instead of ¥4,500, because the builder put a metered price first. The fix went in, and the check went green.

What went wrong, honestly

The workspace ran out of TestSprite credits twice during the hackathon. When that happens the check reports "Not enough credits" without running a single test. Nine pull requests hit that wall; the ones that shipped were merged by the repository admin after every other check had passed. They are not hidden: docs/LOOP.md is generated from the GitHub API and lists every PR and every commit's TestSprite verdict. Five went red on real test results, all fixed in the same PR, and nine were blocked by credits. A credit shortfall is not a test verdict, and treating it as one in either direction would make the ledger lie.

Update, Oct 23. The credit boost arrived. main now requires TestSprite V3, the TestSprite API tests (run against each PR's own preview), the unit tests and the browser journeys, and admins can no longer bypass them. To prove the gate holds, PR #40 planted a one-line bug: proration truncated instead of rounded, so the S05 example billed $103.19 instead of $103.20. 105 unit tests failed, the browser journeys saw the wrong amounts on the preview, and 52 goldens disagreed with Stripe's own invoices. It was closed without merging. Every PR since has gone green through the full gate. One of them added Stripe's one-off invoice items, probed eight ways before any rule was written. The fuzzer then found one more rule: a coupon never discounts a one-off credit.

A second lesson: every new test layer I added found something about the previous layers. Schemathesis found the OpenAPI spec looser than the validator. Redocly Respect's strict schema checks found my conditional schemas rejecting properties their parent declared. Then my fix for that made Schemathesis unable to generate requests at all. Each layer is cheap. Not running the next one is what gets expensive.

If you build something similar

Pick an oracle that is not your code. For billing it is Stripe's test clocks. For tax it could be a published calculator. For physics, a reference implementation.
Derive expectations by hand and write the arithmetic next to them. Future you will need it when the oracle disagrees.
Let the oracle generate the questions too (differential fuzzing), and turn every disagreement into a pinned example.
Keep your end-to-end tests in the repo and check the cloud copy against it.

Try it: open the simulator on S05, change the upgrade date, and press Verify in Stripe. Your own timeline gets replayed in a fresh test clock and diffed to the cent.

AI disclosure: this post was drafted by an AI agent (Claude Code) from the project's own repository, evidence files and CI history, and published at the author's request. The project itself was built with the same agent.

Migrating Yearn Finance's Strategy Template from Brownie to ApeWorx Ape — A DeFi-Specific Case Study

Pugar Huda Mantoro — Sat, 02 May 2026 10:48:14 +0000

Migrating Yearn Finance's Strategy Template from Brownie to ApeWorx Ape — A DeFi-Specific Case Study

Codemod "Boring AI" Hackathon · DoraHacks 2026
Source: github.com/PugarHuda/brownie-to-ape
Companion case study: token-mix end-to-end (Medium)

Why pick Yearn?

Of the five OSS Brownie projects I validated this codemod against, yearn/brownie-strategy-mix is the most production-relevant. Yearn Finance is one of the largest yield-aggregation protocols in DeFi, with billions in TVL at peak; this repo is the official template every Yearn strategy developer forks to build a new strategy. If a codemod can clean-migrate this template, it can handle the strategy contracts that followed — and there are dozens of them across forks, partners, and audits.

The template is also intentionally complex: it ships with a multi-network config, mainnet-fork test fixtures, whale-impersonation patterns for testing real-world deposits, and Brownie-specific testing idioms that exercise edge cases the codemod rarely sees in tutorial repos.

This case study walks through the full migration: what the codemod handled, what required manual cleanup, and how the design of the codemod (FN-over-FP, AST-strict guards) interacted with Yearn-shaped code in particular.

The starting point

Cloning the repo:

git clone https://github.com/yearn/brownie-strategy-mix.git
cd brownie-strategy-mix

Source structure (Python only — Solidity contracts are out of scope):

brownie-strategy-mix/
├── brownie-config.yaml
├── conftest.py
├── tests/
│   ├── test_operation.py
│   ├── test_revoke.py
│   ├── test_emergency_exit.py
│   └── conftest.py
└── scripts/
    └── deploy_strategy.py

7 Python files, ~600 LOC total. Brownie idioms in use:

from brownie import accounts, network, chain, Contract, Wei — most of the standard import surface
accounts.at(address, force=True) — the whale-impersonation pattern (Yearn tests deposit large amounts from real holder addresses)
chain.sleep(N) and chain.mine(N) — for time-locked exit fees
interface.IERC20(addr) — for ERC-20 balance assertions
tx.events["Transfer"].values() — for event verification
pytest.fixture(autouse=True) def isolate(fn_isolation): pass — Brownie's chain-rewind boilerplate

Running the codemod

npx codemod@latest @pugarhuda/brownie-to-ape -t .

Output:

💥 Workflow started with ID: ...
⏺ Apply Brownie -> Ape transforms to Python files
{"codemod":"brownie-to-ape","edits":7,"wei_rewritten":true,"unknown_exceptions":[],"rewrote_brownie_attr":false}
{"codemod":"brownie-to-ape","edits":12,"wei_rewritten":false,"unknown_exceptions":[],"rewrote_brownie_attr":true}
{"codemod":"brownie-to-ape","edits":5,"wei_rewritten":false,"unknown_exceptions":[],"rewrote_brownie_attr":false}
{"codemod":"brownie-to-ape","edits":4,"wei_rewritten":false,"unknown_exceptions":[],"rewrote_brownie_attr":false}
✅ Workflow completed successfully in 3.0s

Result: 4 of 7 .py files modified, ~33 patterns auto-migrated, 3 seconds.

git diff --stat:

 conftest.py                  | 11 ++++++-----
 scripts/deploy_strategy.py   |  4 ++--
 tests/conftest.py            | 13 ++++++-------
 tests/test_operation.py      | 24 +++++++++++++-----------
 4 files changed, 27 insertions(+), 25 deletions(-)

What the codemod handled cleanly

1. Imports — multi-line, mixed types

# Before
from brownie import (
    accounts,
    network,
    Contract,
    Wei,
    config,
    chain,
)

# After
from ape import accounts, networks, chain, config
from ape.utils import convert
# TODO(brownie-to-ape): no direct Ape equivalent for: Contract

Notes:

network → networks rename applied
Wei removed from import line because the codemod auto-rewrites Wei(...) to convert(...) and adds the from ape.utils import convert line
Contract flagged as a TODO because it's an artifact name — the user must decide whether to use ape.Contract (for arbitrary-address loading) or project.<Name> (for compile-time artifacts). The codemod can't infer this without project schema.

2. The whale-impersonation idiom

# Before
@pytest.fixture
def whale(accounts):
    return accounts.at(WHALE_ADDRESS, force=True)

# After
@pytest.fixture
def whale(accounts):
    return accounts.impersonate_account(WHALE_ADDRESS)

This is Pass 7b of the codemod — the strict guard requires force=True to be present (bare accounts.at(addr) is a different operation in Ape, used for already-known accounts, and we don't want to over-rewrite). It fired correctly here because the Yearn test pattern always uses force=True for whales.

3. Time and block control

# Before
chain.sleep(WAITING_PERIOD)
chain.mine(1)

# After
chain.pending_timestamp += WAITING_PERIOD
chain.mine(num_blocks=1)

The chain.sleep rewrite only fires on statement form (Pass 6); if chain.sleep(N) were inside another expression like chain.sleep(N) + something, it would be left alone (FN over FP).

4. tx-dict to kwargs across multi-line deploy calls

# Before
strategy = Strategy.deploy(
    vault,
    strategist,
    {"from": gov, "value": Wei("0.1 ether")},
)

# After
strategy = Strategy.deploy(
    vault,
    strategist,
    sender=gov,
    value=convert("0.1 ether", int),
)

Both transforms in one call: tx-dict rewrite (Pass 4) + Wei rewrite (Pass 9) with auto-import of convert. The whitelist guard verified all keys in the dict (from, value) are valid tx-dict keys before firing — if there had been an extra key like priority_fee (which Brownie supports but Ape doesn't have a direct mapping for), the codemod would have skipped this rewrite to avoid information loss.

5. Network detection

# Before
if network.show_active() == "mainnet-fork":
    fee = HIGH_FEE
else:
    fee = LOW_FEE

# After
if networks.active_provider.network.name == "mainnet-fork":
    fee = HIGH_FEE
else:
    fee = LOW_FEE

Pass 2b — bare network.show_active() (without brownie. prefix). Required because network was imported directly from brownie.

What the codemod surfaced as TODOs

After the codemod, these are the remaining manual items:

$ grep -rn "TODO(brownie-to-ape)" --include="*.py" .
./conftest.py:8: TODO(brownie-to-ape): no direct Ape equivalent for: Contract
./conftest.py:15: TODO(brownie-to-ape): no direct Ape equivalent for: Strategy
./tests/conftest.py:6: TODO(brownie-to-ape): no direct Ape equivalent for: Vault
./tests/conftest.py:7: TODO(brownie-to-ape): no direct Ape equivalent for: Token
./tests/test_operation.py:2: TODO(brownie-to-ape): preserve_web3 — review whether to migrate to convert(...)

5 TODOs total — 4 contract-name flags and 1 web3-preserve note.

These cannot be auto-resolved without project schema introspection (the jssg sandbox has no filesystem access, so it can't read contracts/*.sol to find contract names). Each TODO needs a human or AI agent to decide:

Contract flag — decide between ape.Contract(addr) (loads any address with auto-fetched ABI) or use the existing project artifact pattern.
Strategy, Vault, Token flags — these are project-specific contracts. The fix is project.Strategy, project.Vault, project.Token. An AI agent reads the TODO + the surrounding code and applies the right project.<Name> prefix.
preserve_web3 — one test uses web3.eth.get_balance(). The codemod's Pass 16 flagged this as a TODO because the Ape equivalent depends on whether the user wants networks.provider.web3 (raw web3 access) or chain.provider.get_balance() (Ape-native).

The AI/manual cleanup pass

Following the codemod's TODO comments, the AI cleanup edits look like this:

--- a/conftest.py
+++ b/conftest.py
@@ -5,7 +5,7 @@ from ape import accounts, networks, chain, config

 @pytest.fixture
-# TODO(brownie-to-ape): no direct Ape equivalent for: Strategy
 def strategy(gov, vault, strategist):
-    return Strategy.deploy(vault, strategist, sender=gov)
+    return project.Strategy.deploy(vault, strategist, sender=gov)
+
+from ape import project

The project import is added once at the top of each file that needs it. Total AI/manual cleanup: ~12 lines across 3 files to resolve all 5 TODOs.

What's different vs token-mix

The token-mix migration (companion case study) is a tutorial repo with simple ERC-20 patterns. Yearn's strategy template is more complex in three specific ways:

Multi-network config. The brownie-config.yaml has separate entries for mainnet, mainnet-fork, polygon-main, etc. The Python helper migrate_config.py translates these to ape-config.yaml's networks: block. Result: all 4 network entries translated cleanly with 0 manual edits to the YAML.
Whale impersonation is core, not edge case. Tutorial repos rarely test with real holder addresses. Yearn does this for every operation test. The codemod's Pass 7b (accounts.at(addr, force=True) → impersonate_account) fired exactly once per test fixture, and the rewrite is semantically correct because both are doing the same thing under the hood: bypass the chain's "is this account unlocked?" check.
Contract flag is more painful. Yearn's strategy template uses Contract(VAULT_ADDRESS) (for already-deployed yearn vaults) AND Strategy.deploy(...) (for the new strategy). The codemod flags both with the same TODO comment, but the right Ape equivalent differs:
- Contract(addr) → ape.Contract(addr) (this is automatic if from ape import Contract is added)
- Strategy.deploy(...) → project.Strategy.deploy(...) (compile-time project artifact)

An AI cleanup agent reading the surrounding code can disambiguate: if the variable name is an address constant (VAULT_ADDRESS = "0x..."), it's ape.Contract(addr); if it's a contract artifact name being deployed (Strategy.deploy(...)), it's project.Strategy.deploy(...).

Migration coverage scorecard

Following the hackathon scoring formula Score = 100 × (1 − ((FP × wFP) + (FN × wFN)) ÷ (N × (wFP + wFN))):

Total patterns visible in the repo (N): ~33 across 7 files
Auto-migrated (deterministic): ~28 patterns
TODO-flagged (FN, intentional): ~5 patterns (4 contract names + 1 web3 preserve)
Incorrect rewrites (FP): 0 — verified by manual diff audit and by running the test suite (post-cleanup)

Auto-coverage: ~85%. Manual-cleanup time: ~5 minutes for someone who's read the codemod's TODO comments and knows Ape's project.X pattern. AI cleanup: even faster since the TODOs are unambiguous.

What this proves

The codemod scales beyond tutorial repos. Yearn's strategy template uses every advanced Brownie idiom (whale impersonation, multi-network config, complex tx-dict shapes, mixed contract types). All of them migrate correctly, with the FN-over-FP design making the remaining manual work trivially identifiable.
The "why we don't auto-rewrite contract names" rationale holds in production code. A codemod that tried to auto-prefix Strategy with project. could break repos where Strategy is imported from elsewhere (a base class, a helper module). Strict scoping requires project schema, which jssg sandboxes deliberately don't have. The TODO approach is the right answer here.
DeFi-specific patterns aren't special. The patterns that look unique to DeFi (whale impersonation, multi-network, mainnet forking) all reduce to standard codemod transforms when broken down. The FP-vs-FN tradeoff is the same for tutorial repos and Yearn.

Reproducibility checklist

To verify these results yourself:

git clone https://github.com/yearn/brownie-strategy-mix.git
cd brownie-strategy-mix

# Apply codemod
npx codemod@latest @pugarhuda/brownie-to-ape -t .

# Inspect result
git diff --stat
grep -rn "TODO(brownie-to-ape)" --include="*.py" .

# Run config translator
python /path/to/brownie-to-ape/scripts/migrate_config.py .

Expected output: 4 files changed, ~33 patterns rewritten, 5 TODO comments inserted, 0 incorrect changes.

For the full 5-repo benchmark including this one, see the case study repo.

Acknowledgements

Yearn Finance for the open-source strategy template that made this validation possible.
ApeWorx for the Ape framework and the official Brownie migration guide.
Codemod for the jssg engine and the hackathon framing.
Anthropic Claude for collaborative authoring of test fixtures and the AST exploration that informed the FP-guard design.

Source: github.com/PugarHuda/brownie-to-ape · v0.7.8 · MIT
Codemod registry: @pugarhuda/brownie-to-ape
Related: token-mix end-to-end case study · engineering tradeoffs