DEV Community: Rebel Studios

Reading Zora Creator Rewards on Base When Nothing Is Indexed

Rebel Studios — Tue, 22 Sep 2026 14:15:30 +0000

Originally published on rebelstudiossoftware.com.

Every trade of a Zora coin pays several people at once: the coin’s creator, the platform that launched it, the app that routed the trade, the protocol, and Doppler. If you create coins, run a platform that launches them, or build an app that passes a referrer on trades, some of that money is yours. Zora’s REST API won’t tell you how much. The payouts are onchain, one event per trade, and getting yours out takes one idea and some patience.

The event, and the problem with it

Coins launched since Zora moved to Uniswap V4 pay rewards through their hook, which emits CoinMarketRewardsV4. Its payload is seven addresses (the coin, the currency the reward is paid in, then the creator, platform referrer, trade referrer, protocol and Doppler recipients) followed by ten amounts: for each of those five recipients, what they got in the currency and what they got in the coin itself.

None of those fields is declared indexed, and that one detail decides everything. A log’s indexed fields go into its topics, and topics are what eth_getLogs filters on. This event has a single topic, its own signature. So you can ask a node for every CoinMarketRewardsV4 event in a block range, but not for the ones that pay you. Your address is in the data, where the node doesn’t look.

Coins from before the V4 migration use an older event, CoinTradeRewards, which does index its three recipients, so an ordinary address filter works for them. For anything launched since mid-2025, it doesn’t.

One more V4 event pays creators. On creator-coin trades the hook also emits CreatorCoinRewards: the coin (indexed), the currency, the creator and the protocol, then the creator’s and the protocol’s amounts. The recipients aren’t indexed there either, and the event is easy to miss, but it matters: in a sample day on Base it carried about a third of all payouts and nearly half of what creators earned. A scan that reads only CoinMarketRewardsV4 under-counts a creator by that much.

So read all of them

The fix is unglamorous: fetch every reward event in a range, decode it, and keep the ones where your address is one of the three recipients. On Base today that’s about 400 events per 2,000 blocks. Here’s the whole thing with nothing but JSON-RPC:

import httpx

RPC = "https://mainnet.base.org"
# keccak256 of the two V4 payout events' signatures (topic 0 of each log)
MARKET = "0x35b5031218696db1dfd903223a47f38e66a1998e14a942a5d60fddaa49a685fc"        # CoinMarketRewardsV4
CREATOR_COIN = "0xea92473287be4e55f8279d0b8395a45960a217ae2f1a76ac9cae84af58a751ed"  # CreatorCoinRewards
ME = "0x55c88bb05602da94fce8feadc1cbebf5b72c2453"

def rpc(method, params):
    body = {"jsonrpc": "2.0", "id": 1, "method": method, "params": params}
    return httpx.post(RPC, json=body, timeout=30).json()["result"]

head = int(rpc("eth_blockNumber", []), 16)
logs = rpc("eth_getLogs", [{"fromBlock": hex(head - 2000), "toBlock": hex(head),
                            "topics": [[MARKET, CREATOR_COIN]]}])

addr = lambda word: "0x" + word[-20:].hex()
for log in logs:
    data = bytes.fromhex(log["data"][2:])
    w = [data[i:i + 32] for i in range(0, len(data), 32)]
    if log["topics"][0] == MARKET:
        # words 0-6: addresses; 7-16: amounts (per role, in currency then in the coin)
        currency = w[1]
        roles = [("creator", w[2], w[7]), ("platform referrer", w[3], w[9]),
                 ("trade referrer", w[4], w[11])]
    else:
        # the coin is in topic 1; words: currency, creator, protocol, then their two amounts
        currency = w[0]
        roles = [("creator", w[1], w[3])]
    for role, who, amount in roles:
        if addr(who) == ME:
            block = int(log["blockNumber"], 16)
            print(block, role, int.from_bytes(amount, "big"), "of", addr(currency))

The data is plain ABI encoding: 32-byte words with addresses right-aligned and amounts as big-endian integers. CoinMarketRewardsV4 has seven addresses then ten amounts; CreatorCoinRewards has three addresses then two. Amounts are in the token’s smallest unit, so 486910 of USDC (0x8335…2913) is 0.486910 USDC, and 18-decimal tokens like ZORA and WETH need dividing by 1018.

Scanning a real window

One call covers 2,000 blocks. Base makes a block every two seconds, so that’s about 67 minutes; a day is 43,200 blocks (22 calls) and 30 days is about 650 calls. A few details make that practical:

Time is arithmetic. Base blocks are exactly two seconds apart, so a block’s timestamp is 1686789347 + 2 × block. You don’t need an eth_getBlockByNumber per event to date it, and “the last seven days” is a subtraction from the head block.
Start where the events start. The first V4 reward events show up around block 31,000,000, in June 2025. There’s nothing to find before that.
Expect range errors. Public RPCs cap the block range or the number of results per call. When one refuses, halve the range and retry instead of failing the whole scan.
Remember what you’ve scanned. Store the block ranges you’ve covered for each address and only fetch what’s new next time. The second run of a 30-day report should take seconds.
Price it at the end. Rewards arrive in ZORA, WETH, USDC or a creator coin. Sum raw amounts per role and token first, and convert to dollars once, when you report.

Or use the library

All of that is the rewards module in the Zora Coins SDKs, which are open source and MIT licensed. In Python:

from zora_coins.rewards import RewardsIndexer, build_report, to_text

me = "0x55c88bb05602da94fce8feadc1cbebf5b72c2453"
with RewardsIndexer("rewards.sqlite") as idx:
    idx.scan([me], days=7)          # re-running only fetches blocks it hasn't seen
    print(to_text(build_report(idx.events_for([me]), [me])))

For about an hour and a half of blocks, that printed:

Zora rewards for 0x55c88bb05602da94fce8feadc1cbebf5b72c2453
114 reward events, blocks 51477712–51479837
  Platform referral          145.7255 ZORA                $1.18  (7 payouts)
  Platform referral            2.1861 USDC                $2.19  (25 payouts)
  Trade referral               6.7341 ZORA                $0.05  (69 payouts)
  Trade referral          6.21437e-05 WETH                $0.16  (14 payouts)
  Trade referral             0.175478 USDC                $0.18  (14 payouts)
  Total (current prices)                                      $3.76

The same indexer is in the TypeScript, Go, Rust, C#, Java and C++ SDKs, and the Python, TypeScript, Go and Rust packages include it as a zora-rewards command (pip install zora-coins, then zora-rewards --days 7 0xYourAddress). All seven give the same totals, to the wei, on the same set of recorded events. That cross-check is how I know the word offsets above are right.

Unofficial

The SDKs are community-maintained by Rebel Studios and not affiliated with Zora. If Zora changes the event, the recorded-event tests will be the first thing to fail, and the fix will go out as a new version in every language at once.

ATS-Friendly Resume Format: What Actually Parses

Rebel Studios — Thu, 17 Sep 2026 11:21:57 +0000

Originally published on rebelstudiossoftware.com.

Most “my resume gets no responses” problems are not about your experience — they’re about format. An Applicant Tracking System has to parse your document into fields, and the wrong layout garbles it before a recruiter ever searches. Here is the format that actually parses cleanly.

File type: .docx beats a design-tool PDF

A Word .docx is the safest, most universally parseable format. PDFs can parse well — but only if the text is real, selectable text. A PDF exported from a design tool (Canva, InDesign) where the resume is effectively an image will parse as nothing. If you must send PDF, make sure you can select and copy the text.

One column. Always.

Multi-column layouts, tables, and text boxes are the number-one parsing killer. The parser reads left-to-right, top-to-bottom; a two-column design interleaves your sidebar into your job history and turns it to nonsense. Use a single column, top to bottom.

Headings, fonts, and the small stuff

Standard section headings: “Work Experience,” “Education,” “Skills.” Creative headings (“Where I’ve Made Impact”) can miss the parser’s expected buckets.
Common fonts: Arial, Calibri, Georgia, Times. Nothing exotic.
No headers/footers for contact info — many parsers ignore that region. Put your name, email and phone in the body.
No graphics, logos, icons or photos. They carry no parseable text and can break layout.
Consistent dates: one format, e.g. Jan 2023 – Mar 2025, everywhere.

Test it before you trust it

The fastest sanity check: copy all the text out of your resume and paste it into a plain notepad. If the order is scrambled or fields are missing, the ATS sees that same mess. Then check the actual content against each posting — the right format gets you parsed; the right keywords get you ranked.

See your match before you apply

Resume Keyword Matcher is a free Chrome and Firefox extension that reads any job posting, pulls its keywords, and scores how well your resume matches — showing you exactly which terms you’re missing so you can close the gaps before an ATS ever ranks you. Everything runs on your device; your resume never leaves your computer.

Get the free extension →

Related reading: how to get your resume past an ATS and ATS resume keywords.

Selling event tickets on WooCommerce without the per-ticket tax

Rebel Studios — Tue, 15 Sep 2026 11:19:28 +0000

If you run events and a WordPress site, the ticketing math is quietly
brutal. Eventbrite takes roughly $1.79 + 3.7% per ticket. Sell 300 tickets at
$40 and you've handed over ~$500 before your own payment processor takes its cut.
And the "free" WordPress ticketing plugins mostly aren't — the common pattern is a
free RSVP tier with the actual paid-ticket feature locked behind a $75+ upgrade,
sometimes just to turn on Stripe.

Here's the thing: if you already run WooCommerce, you don't need any of that.

Why WooCommerce-native ticketing avoids the fees

WooCommerce already has your payment gateway configured — Stripe, PayPal, whatever
you use. It already handles tax, currency, receipts, and refunds. A ticket is just a
product. So "event ticketing" doesn't need to be a separate platform with its own
cut; it can be a thin layer on top of the checkout you already run.

That changes the fee structure completely:

No per-ticket platform fee. You pay your normal payment-processor rate (~2.9%
- 30¢) and nothing else. On 300 tickets at $40 that's the difference between keeping ~$11,600 vs ~$11,100 — and none of it routed through a third party.
The money lands in your own account, same as every other WooCommerce order — not held by a ticketing company on their payout schedule.
No forced paywall on payments. Taking money should not itself be the premium feature.

What "good enough" ticketing actually needs

For the vast majority of organizers — a workshop, a supper club, a meetup, a class
series — the real requirements are small:

Put a price on an event and take payment through your existing checkout.
Issue a QR-coded ticket by email, automatically, once the order is paid (not when someone abandons checkout — that should never issue a ticket or eat a seat).
Scan the QR at the door to check people in — no separate hardware, no app.
Optionally, multiple ticket types — General / VIP / Early bird — each with its own price and its own capacity that sells out independently.
An attendee list and CSV export.

That's it. Seat maps and reserved seating are a genuinely bigger problem, but most
organizers don't need them and shouldn't pay for a platform that assumes they do.

The build/buy version

I build small WordPress tools, and I made exactly this so I'd stop recommending
Eventbrite to people who already had WooCommerce: Event Tickets & Registration.
The free plugin does unlimited RSVP events with QR tickets and door check-in; the
Pro add-on adds paid tickets through your
own WooCommerce checkout and multiple ticket types — one-time price, no per-ticket
cut, ever. It's a separate download and not required; the free tier stands on its
own.

But the real point stands whether you use it or not: if you're on WooCommerce,
you're already paying for the infrastructure ticketing platforms resell back to you.
Stop paying the per-ticket tax on top.

How to structure a freemium WordPress plugin that passes wp.org review

Rebel Studios — Tue, 15 Sep 2026 01:51:33 +0000

If WordPress.org rejected your plugin for "trialware" or "locked
functionality," you didn't do anything unusual — you did the thing every SaaS
tutorial tells you to do, and it's exactly what the directory forbids. Here's the
rule, and the structure that actually passes.

The rule that trips everyone up

Guideline 5 says a plugin in the directory can't contain locked, disabled, or
paywalled code. The pattern you reach for by instinct — ship one plugin, grey out
the Pro buttons, gate them behind a license check — is trialware, and it's an
automatic rejection. It doesn't matter that the code is GPL. If the free download
contains features the user can't use without paying, it's out.

The structure that passes: two plugins, not one

The free plugin lives in the directory. It is fully functional on its own and contains zero paid code. No disabled buttons, no dead "upgrade to unlock" screens wired to features that ship inside it.
The Pro add-on is a separate plugin you sell off-site (Gumroad, Lemon Squeezy, your own site). When it's installed and licensed, it hooks into extension points the free plugin exposes and adds the paid features.

The free plugin never contains the Pro code. The Pro code never ships in the
directory. That's the whole trick, and it's the difference between approved and
rejected.

The mechanism

The free plugin exposes a filter for its tier and action/filter hooks where an
add-on can attach:

// In the FREE plugin. Ships alone => always false.
function myplugin_is_pro() {
    return (bool) apply_filters( 'myplugin_is_pro', false );
}

// A gated capability degrades to free behaviour, never to a broken screen.
if ( myplugin_is_pro() ) {
    do_action( 'myplugin_render_pro_panel' );
} else {
    echo '<a href="https://your-site.com/pro">Upgrade to Pro</a>';
}

// In the SEPARATE Pro plugin, sold off-site.
add_filter( 'myplugin_is_pro', fn( $v ) => MyPro_License::is_valid() ? true : $v );
add_action( 'myplugin_render_pro_panel', [ MyPro_Feature::class, 'render' ] );

Because the free plugin only ever links out to a sales page and its
myplugin_is_pro() is false when it ships alone, there's no locked code in the
directory download. The value is real (the free tier works), and the upgrade is a
genuine separate product — which is what the guideline actually wants.

Four more landmines (all real, all cost time)

readme.txt is published verbatim. Don't advertise features you haven't built yet — a dead promise on a public plugin page is worse than a missing feature, and reviewers check the code against the readme.
New authors get one plugin in review at a time. Queue matters; you can't parallelise your first few submissions.
Trademark terms are banned in slugs. A slug starting with a protected term (e.g. woocommerce- / wc-) gets rejected on name grounds alone. Put the "for WooCommerce" in the display name, not the slug.
Run Plugin Check before submitting (wp plugin check <slug>). It catches the escaping, i18n, and header issues reviewers would bounce you for — fix them first and you skip a review round-trip.

Skip the boilerplate rebuild

The annoying part is that none of this is your feature — it's the same license gate,
settings framework, wp.org-ready readme, and build-to-zip you rewrite every time. I
packaged the whole compliant structure (plus a one-command scaffolder that stamps out
a namespaced, activation-ready plugin) so you add your feature and ship:
Freemium WordPress Plugin Boilerplate.
Optional — the structure above is the real lesson, and it's yours whether you build it
by hand or not.

Why the ATS says you’re “missing” keywords your resume clearly has

Rebel Studios — Mon, 14 Sep 2026 20:40:35 +0000

Every "ATS keyword" checker tells you the same demoralizing thing: you're missing
skills you know are on your resume. You wrote "managed a team of six" and it says
you're missing management. You wrote "analyzed sales data" and it flags data
analysis as absent. So you start stuffing exact phrases into your resume to satisfy
a robot — and the result reads like it was written by one.

Here's the thing: the robot is usually wrong, and it's wrong in a specific,
fixable way.

Most keyword matchers do dumb string comparison

Under the hood, a lot of these tools check whether the exact word from the job post
appears in your resume. The job says "management"; your resume says "managed." Those
aren't the same string, so — missing. It doesn't know that:

managed / managing / manager / management are the same skill (morphology),
stakeholders and stakeholder are the same thing (plurals),
"data analysis" and "analyzed data" are the same thing (word order),
JS and JavaScript, k8s and Kubernetes are the same thing (synonyms).

A real ATS (Workday, Greenhouse, Lever) is more forgiving than the cheap checkers —
it does stemming and synonym expansion. So when a checker screams that you're missing
ten keywords, most of those are false alarms, and chasing them makes your resume
worse, not better.

How to actually check your match

Reduce both sides to concepts, not strings. For each "missing" keyword, ask: does my resume show this idea in any form? If yes, it's a false alarm — leave it.
Only fix genuine gaps. If the job wants "Kubernetes" and you've genuinely never touched it, no keyword trick fixes that — and you don't want it to.
Match the job's phrasing once, where it's true. If you do have the skill but worded it oddly, align to the job's term a single time. Don't carpet-bomb.
Write for the human. The recruiter reading after the ATS is the real gate. A keyword-stuffed resume passes the filter and fails the person.

A tool that does the tolerant version

I got annoyed enough at the false "missing" flags that I built a small Chrome
extension that does the tolerant matching — stemming, plurals, word-order, and
common acronyms — so it only flags a skill as missing when your resume genuinely
doesn't show it. Free (3 checks/day), runs entirely on your device, nothing uploaded:
Resume Keyword Matcher for ATS on the Chrome Web Store. Built it for exactly this
problem; sharing in case it saves someone the phrase-stuffing spiral.

(If you just want the principle: stop optimizing for string-match robots and start
checking whether the concept is present. That alone fixes most of the panic.)

I build small, honest tools at rebelstudiossoftware.com. This one's a free Chrome extension — search "Resume Keyword Matcher for ATS".

How to Get Your Resume Past an ATS in 2026

Rebel Studios — Mon, 07 Sep 2026 22:29:38 +0000

Originally published on rebelstudiossoftware.com.

If your applications keep vanishing into a black hole, the culprit is usually an Applicant Tracking System (ATS) — the software almost every mid-size and large employer uses to receive, parse, and rank resumes before a human sees them. The good news: getting past it is mechanical, not mysterious.

What an ATS really does (and doesn't)

Kill the biggest myth first: a modern ATS does not usually auto-reject resumes on its own. It parses your resume into structured fields (name, work history, skills, dates) and makes you searchable and rankable for the recruiter. You get filtered out when your resume either parses badly (so your experience lands in the wrong fields or gets lost) or doesn't match the keywords the recruiter searches for. Both are fixable.

The two real reasons resumes fail

Parsing failure. Columns, tables, text boxes, headers/footers, and graphics confuse the parser, so your data is garbled or dropped.
Keyword mismatch. The recruiter searches for the skills in the job description; if your resume uses different words for the same thing, you don't surface.

How to get past it, step by step

Mirror the job posting's language. If the posting says "CI/CD," don't only write "build pipelines." Use the posting's exact terms where they're truthfully yours — that's what the recruiter searches.
Use a clean, single-column format. Standard headings ("Experience," "Education," "Skills"), a common font, consistent dates, no graphics.
Quantify. "Cut build times 40%," "handled 2M requests/day."
Match before you send. Compare your resume against each specific posting and fix the missing keywords — the single highest-leverage step, and the one people skip because it's tedious by hand.

What NOT to do

Don't stuff invisible white-text keywords or paste the whole job description into your resume — recruiters see the parsed text and it reads as spam. Don't use a PDF exported from a design tool where the text is an image. And don't send one generic resume to every job; the keyword match is per-posting.

I got tired of doing step 4 by hand, so I built a free Chrome extension — Resume Keyword Matcher — that reads any job posting, pulls its keywords, and scores how well your resume matches, showing exactly what's missing. Everything runs locally; your resume never leaves your device. It's here if it's useful.