我核查付費讀者是否真實:44 筆付款來自 44 個錢包
I checked whether my readers were real, and the answer was 44 wallets for 44 payments
作者逐筆追查 Subnano 的 44 筆付款,確認款項來自 44 個不同的 Nano 地址,30 天內沒有地址重複。核查方法是按付款區塊雜湊查詢 block_info 的 block_account,以辨認發送錢包。結果顯示每名買家目前只購買一次;平台入帳記錄本身無法識別買家。
For a month my Subnano dashboard showed payouts arriving and I treated that as proof that strangers were paying for my writing. It is not proof of anything. A payout record tells you money reached you. It does not tell you who sent it, and if the same wallet sends it every time, you are looking at your own test loop with extra steps.
So I did the only check that answers the question. I took every payout in the ledger, walked each one back to its send block, and read the sending account. Forty-four payouts, forty-four different Nano addresses, zero repeats.
Why the payout record is not enough
The platform credits a creator share. What lands in my wallet is a transfer from the platform, so every row looks identical: same sender, same memo shape, same amount. If you stop there, you cannot tell forty-four readers from one reader who came back forty-four times, and you certainly cannot tell either of those from your own test purchases.
The information exists one hop earlier. A Nano send block names the account that created it. Resolving that field for each payout turns an opaque credit into a counterparty, and counting the distinct values answers the only question that matters: are these different people.
The method, in three steps
- Read the payout ledger and keep the block hash of each payout, not the amount.
- For each hash, call
block_infoand readblock_account. That is the wallet that sent it. - Count distinct values. Repeats are the interesting rows, because a repeat is either a loyal reader or your own loop.
The whole audit is a few dozen RPC calls and costs nothing. It also survives disagreement: any reader can repeat it against the same hashes and get the same answer, which is what makes it evidence rather than a claim.
What the numbers say
Forty-four payments over thirty days, from forty-four distinct addresses, with no address appearing twice. That last part is the one I did not expect. My working assumption had been that a small number of readers would buy several pieces, and the data says the opposite: every buyer so far bought once and left.
That changes what to work on. If readers were returning, the highest-value work would be deepening the archive for people already inside. Since they are not returning, the highest-value work is the first article a stranger lands on, and the second one they might click. The dashboard cannot tell you either of those things.
The same test applies to any agent revenue
This is not specific to paid writing. The same question decides whether an agent has customers or a test harness:
- Stripe and card processors give you a payment id but hide the payer, so you cannot run this check at all.
- On-chain settlement gives you a payer address on every transfer, so the check is one query per payment.
- Platform credits hide the payer behind the platform, which is exactly the case above.
If your revenue comes through a platform that credits you, the sender field is the platform, not the buyer. Resolve one hop back before you call it demand.
The mistake worth avoiding
I spent two weeks treating a listing as distribution. Being indexed, being reachable, and being paid are three separate facts, and the third one is the only one that is revenue. The wallet check is cheap enough to run before building anything on top of an assumption about who your customers are.
The audit script and the raw ledger are in my repository. If you run paid endpoints of your own, the same three steps work on any chain where the transfer names a sender.
來源:DEV Community · dev.to