CashQ

The problem

Stable YouTube creators earn every day, but Google pays between the 21st and 26th of the following month. Production costs come in every week. The credit options on offer all fail them:

• Banks refuse creators without collateral or a payslip.

• Salary-advance apps only serve employees with an employer.

• Online lenders charge 0.3% per day.

• Creator-financing firms like Spotter and Bump focus on large channels, and nothing stops the same payout from being funded twice by different apps.

The market is large and proven:

• YouTube Partner Program paid out more than $70 billion over three years.

• Indonesia ranks 4th worldwide with 151 million users and about 3,000 channels above 1M subscribers.

• Spotter has funded around $600 million, which shows demand. Its drop (concentration in a few stars, then the shift to Shorts) shaped our design.

Existing players

• MilX has two products: Advance Funds (earned, unpaid money) and Active Funds (projected earnings up to 6 months), with auto-repay when the payout lands. It has processed $500M+ in creator revenue across 5,000+ creators in 44 countries and advanced $17.6M. Capital is closed and there is no Southeast Asia coverage.

• CreatorAdvance uses official read-only YouTube OAuth, advances 50–80% of monthly earnings, charges a flat 4–10% fee, and repays automatically. It serves only the US, Canada, the UK and Australia.

• Fundmates has funded $50M+ across 250+ channels with closed capital.

• Spotter has funded $940M across 735+ channels, backed by a $200M Series D from SoftBank. Capital is closed and underwriting is opaque.

Every one of them runs as a private web2 balance sheet. None offers an open on-chain pool, a nullifier against double funding, or a focus on Southeast Asian creators. CashQ targets that gap.

What CashQ does

CashQ advances part of AdSense earnings that are already final. Google has fixed the amount and will pay it between the 21st and 26th. The creator logs into their own AdSense account, CashQ seals proof of the balance cryptographically, and the money is released. When the Google payout arrives, the system takes the advance back automatically. The creator sees a single flat fee upfront.

Core mechanisms

1. Two-path verification. The main path is zkTLS. The creator logs in, their browser session is sealed cryptographically, and the proof binds to that creator. The second path is the official YouTube Analytics API, used as supporting data and as a fallback. A fallback proof gets a lower advance limit. The zkTLS scope is one page: the creator’s AdSense Payments page. It reads only the final balance posted on the 3rd, the amount due on the 21st–26th. Payout history stays out of the proof. A separate data path (OAuth Analytics) feeds that to the bureau system.

2. Bureau system (rule-based). An automated scorer decides what percentage of the balance a creator can withdraw. It uses explicit rules, not an AI model, over six historical signals: niche decay, trend direction, monthly volatility, upload consistency, fake-traffic anomalies, and invalid-traffic buffer ratio. Every score point can be explained to the creator, the same channel always gets the same answer, and the weight table can live on-chain where nobody can change it quietly.

3. Advance with no guessing. CashQ advances only against the final balance Google posts around the 3rd, available until the 20th. Nothing is predicted. Google withholds US tax upfront, so the limit is calculated after tax: up to 90% for creators with good history and a clean record, and up to 70% for new creators. Advances in the window with no final balance (21st–3rd) come later, underwritten by the bureau system.

4. Automatic repayment. Repayment runs through Bank Indonesia-licensed open finance (Ayoconnect). The creator binds a bank account once, like a Google Play subscription, and repayment is debited when the payout lands. A second option is a named virtual account as the payout destination. It gives the strongest repayment but takes days to verify.

5. No double funding. Each payout gets a unique on-chain nullifier. Any lender can check whether a payout is already taken, so two apps cannot advance against the same money.

6. Three-layer pool. Investor funds split into a senior layer, a junior loss buffer, and a reserve. When an advance defaults, the junior layer absorbs the loss first and the senior layer last. The reserve covers losses that exceed expectations.

7. Credit record. Every on-time repayment is written on-chain as a permanent history that belongs to the creator. They can take it to any lender. If CashQ shuts down or raises fees, the clean record stays with them.

Basic flow

1. The creator logs into Google and runs zkTLS on the AdSense page.

2. The system reads the final balance due on the 21st.

3. The bureau system (rule-based) sets the withdrawable amount.

4. The creator binds a bank account, like a subscription.

5. The advance is paid today, with the fee shown upfront.

6. On the 21st, the Google payout lands in the account.

7. Auto-debit takes the advance plus the fee.

8. The creator keeps the rest of the payout, and an on-time record is written on-chain.

Why on-chain

The problem blockchain solves is one payout being funded twice. The fix is a registry that every lender trusts, and no single company can own it. If CashQ owned it, rival lenders would refuse to put their data in a competitor’s database. On-chain, the nullifier registry belongs to nobody and anyone can read it. Pool rules and credit records sit there as code that nobody can change quietly, so trust shifts from “trust the founder” to “trust the math.”

A normal earned-wage-access product has one bank and one customer, so a database is enough. CashQ has many competing lenders sharing one truth about one payout, and that only works somewhere no one owns.

Business model

• Flat fee of 2.5–3% per advance, shown upfront, no interest, no tips. Compare that with online lenders at 0.3% per day.

• Pool take rate from the fees that flow to fund providers.

• Later: a paid anti-stacking API for web2 lenders (built on the nullifier registry), bureau licensing, and growth notes through OJK-licensed partners for creators with clean records.

Tech stack

• On-chain: Foundry/Anvil. ERC-4626 vault (three layers), nullifier registry, waterfall sweep. ERC-4337 smart account for the repayment rail. Time warp to the 21st in the demo.

• zkTLS: zkPass TransGate (3P-TLS via Chrome extension, @zkpass/transgate-js-sdk). One custom schema intercepts the mock AdSense Payments API. The only claim is the final balance on the 3rd, with the nullifier taken from payment_id. No payout history.

• Data: YouTube Analytics OAuth (yt-analytics-monetary.readonly) for historical estimates. Open finance API (mock Ayoconnect) for debit.

• Bureau system: a pure rule engine, if-then over historical revenue numbers pulled through its own data path (OAuth Analytics), not from the zkTLS proof. The weight table can sit on-chain.

• Demo: mock YouTube Studio/AdSense, a payments page, and a “rogue lender.” The on-chain parts are live: nullifier, waterfall, pool.

Hackathon scope

To keep the 12-hour demo stable, some mechanisms are simplified. The full design above stays the target.

• Advance and repayment fully on-chain. Advance funds go to the creator’s wallet, the YouTube payout is assumed to land in that wallet, and auto-debit pulls from it. This replaces the open-finance and bank rail, which needs a licensed partner.

• zkTLS verification only. The OAuth Analytics path is cut.

• Bureau system as a data viewer. The rule engine shows channel data on a dashboard (trend, volatility, consistency) but does not set the advance percentage. The percentage is fixed for the demo.

• Single-layer vault. No senior/junior/reserve. All LPs hold one deposit type and earn the same yield.

• Credit record as transaction history. Verification logs, advance requests, auto-debit runs, and their status (success/fail) are recorded and visible. No portability between lenders.

• Mock stablecoin: IDRX as the asset for the pool and advances.

After the hackathon

• Predictive advances in the dark window (21st–3rd)

• Named virtual accounts for the full advance ratio

• Pool funding through LP providers (the vault as pipe, providers as water)

• Growth notes for production financing

Pitch Deck: https://canva.link/fi1zygcjzqydi9e

I built CashQ alone over two days. Two things took most of that time.

zkTLS with zkPass. zkPass is a young product and its documentation has gaps. Several times the docs did not cover my case, so I worked through it by trial and error: writing the custom schema, validating it with the Schema Validator extension, and wiring TransGate into the app. Getting a proof of the final AdSense balance to verify end to end was the hardest part of the project.

Vite + React. This was my first project on Vite and React. I learned the framework while building the demo, which cost me time early on and shaped how I structured the frontend.

Despite both, the core idea is intact: a creator proves a finalized AdSense balance with zkTLS, and the advance is tied to that proof.

I have not raised any funding. No investors are committed and no fundraising conversations have started. CashQ is at the hackathon prototype stage.