A founder note on what we shipped, who we shipped it for, and the place the two audiences meet.

I wrote recently about three curves crossing at the authentication layer of the internet: software becoming an economic actor, real-world value moving into wallets, and the slow collapse of the long-lived secret. That essay, From Passwords to Proofs, was the thesis. This one is the inventory. Less about where things are going, more about what we actually put in the world while we waited for them to arrive.

So here is the honest accounting. Not a roadmap. Not a vision deck. The things that respond when you call them today, sorted by who they were built for.

The primitive, in one sentence

Everything we ship sits on top of one small idea. Read wallet state, evaluate it against a condition, return a signed boolean. That is InsumerAPI, and it is the only thing we invented. Everything else is an arrangement of it. It answers one question at a time, and the answer is an ECDSA-signed yes or no that anyone can check offline against the public key we publish at insumermodel.com/.well-known/jwks.json. It never returns the balance. It returns whether the condition was met, signed and dated, and nothing else.

Two things about that are easy to skip past. The first is the shape of the answer. A boolean is not a limitation, it is the discipline. To read a wallet we ask only what the condition needs, so we collect the minimum. To answer, we return only met or not met, so we expose the minimum. The shopper proves they qualify without revealing what they hold; the merchant learns the condition was met without learning anything else. We see a wallet address and public chain state, never a person. Minimal in, minimal out, by construction.

The second is the public key. Because every answer is signed against a key we publish openly, anyone can check it offline, with no call back to us, today or years from now. That same file is how the system survives the future. If the signing algorithm ever has to change, for post-quantum reasons or any other, we rotate the key, publish the new one to the same JWKS file, and every verifier picks it up automatically. No hard fork, no reissue, no coordination across anyone. The receipts you hold today still check out; the proofs issued tomorrow use the new scheme. The audit surface never moves.

It is in production, reading wallet state across thirty-seven blockchains for live callers. The clearest example is AsterPay, a Circle member and payment processor that calls /v1/attest to make wallet-state decisions its own merchants can independently verify. They could read a balance themselves. They use signed attestations because a merchant accepting their decision will not take their word for it, and a signature against a public key means the merchant does not have to.

That is the whole primitive. Everything below is composition. Some of it we built for people. Some of it we built for agents. The interesting part is that it is the same read underneath.

What we built for people

Start at the cash register, because that is where most people will meet this first.

A merchant who wants to reward the people who hold their token, or their NFT, or one day their tokenized shares, used to need a database, a list, and a way to defend both. We replaced that with three free tools. InsumerDashboard is where a merchant sets the conditions: hold this token above this threshold, get this discount tier. InsumerScanner is the point-of-sale side, a QR scan that confirms a customer qualifies and applies the discount without the cashier ever seeing a wallet. InsumerRegistry is where a token or NFT project registers itself so merchants can recognize it. Call them the merchant tools. The merchant configures once. The proof happens at the counter.

This is the surface that grows as tokenized assets land in wallets. Today it rewards a community for holding a memecoin or a membership NFT. Some of those tokens already stand for soccer clubs. Picture a bar near a stadium during the World Cup that wants to fill tables on match day. It offers a round at a discount to anyone whose wallet holds their club's fan token. The supporter taps a phone at the counter, the read confirms the holding, the drinks come cheaper, and the bar pulls in exactly the fans it was after, without ever seeing a wallet address or a balance. Tomorrow, when equities are tokenized, the same flow recognizes that the shopper standing at the counter already owns a piece of the company. Walk into a store holding that brand's tokenized shares, and the wallet read at checkout surfaces a discount. The merchant is not handing out a perk for loyalty. It is acknowledging ownership.

The accounting on that is sharper than the marketing. A traditional loyalty program is a balance-sheet liability. Every point issued is something the company owes. A discount based on share ownership is not a liability, because the customer already holds the upside. The CMO gets a loyalty program. The CFO gets the liability off the books. The shareholder gets a tangible reason to hold. We built the part underneath that lets the wallet read be signed, so the merchant is not trusting a stranger's claim about what the wallet holds.

The shopper has two ways in. InsumerPass is for showing up: connect a wallet, prove you hold what the merchant asked for, and at the register show a QR code or tap your phone over NFC. Either way the counter receives your discount tier, never your wallet and never your balances. And the InsumerExtension in the Chrome Web Store does the same job online, from inside the browser. What I like about the extension is where the work happens. It reads your wallet locally, in your own browser, decides which tier you qualify for, and hands the checkout a one-time code plus a discount percentage. The merchant receives the code and the percentage. Never your wallet address. Never your holdings. The proof crosses the counter; the data never does.

InsumerPass also runs the other direction. Instead of waiting until you are at a checkout, open it and it surfaces the participating merchants offering discounts for the tokens already in your wallet, and where to find them. The holding goes looking for the discount, instead of you hunting for one. A token you were holding anyway turns out to be worth something at a shop down the street.

Hiding things in plain sight

The same read that prices a discount can decide whether a page renders at all. That is the second thing we built for people, packaged under our sister company SkyeMeta for anyone who would never want to call an API directly.

SkyeMeta's SkyeGate gates content by wallet condition. A reader connects a wallet, the condition is checked, and the page renders or it does not. What is unusual is the page itself. The URL is public, the HTML shell is indexable, but the gated content does not exist in the rendered page unless the wallet qualifies. A reader without the right wallet sees nothing. A developer opening browser devtools sees nothing. There is no hidden field to inspect and no token to scrape. The sensitive material sits behind a wallet read on an open page on the open web. Secrets in plain sight. It ships free as a WordPress.org plugin and at $49 a month for stacked conditions, more chains, and a Next.js SDK for sites that do not run WordPress.

The same gate has a future inside companies. When equities tokenize, a company can put its shareholder-only material behind a SkyeGate condition: hold the tokenized shares in your wallet, read the investor letter, open the data room, see the board deck. The condition is checked against your wallet the moment you ask, so the access tracks the holding. The day you sell the shares, the next read fails and the door closes on its own. Nobody runs a deprovisioning script, nobody prunes an access list, nobody forgets to remove the holder who exited last quarter. Access is a function of what the wallet holds right now, not a permission granted once and revoked by hand later.

SkyeMeta's SkyeWoo points the same idea at WooCommerce. A shop offers wallet-verified discounts to holders of a token, a DAO, or an NFT collection, without hand-managing a single list. Same license shape, $49 a month.

Step back from the storefront and the pattern generalizes. The real category is condition-based access. Token gating is one slice of it. Think about a problem that has nothing to do with shopping: how do you let only the right people into a Zoom call? The usual answer is a link, which is a secret, which gets forwarded. The wallet-auth answer is a condition. Only wallets that hold the board token, or the ticket NFT, or the membership pass get in, the room checks the condition at the door, and there is no link to leak because there was never a shared secret. Anywhere you currently defend a boundary with a password or a list, a signed condition can stand in.

What we built for agents

The other audience does not have hands. It runs continuously, holds a wallet, talks to other software, and pays for what it consumes. Every assumption behind a password breaks when the user is an agent. It does not remember secrets, cannot be challenged, and has no email anyone owns. So we built the agent side on the same read, shaped differently.

SkyeMeta's AgentTalk is a condition-gated room for agents. We call it a SCIF for agents, after the cleared facility a human can enter only by meeting a condition. An agent approaches a session, its wallet is checked against the condition, and it enters if it qualifies. The check repeats during the session. If the agent falls out of qualification, it is ejected. The room scales the same whether two market-making agents are negotiating or two thousand agent voters are holding a governance call. There is no admin dashboard, because the customer is not a human. The agent pays in stablecoin credits and refills itself when the balance runs low. A year ago this was a slide. Today it has agents in it.

For the API itself, SkyeMeta shipped @skyemeta/access, open-source middleware, MIT-licensed and free. It lets any API accept a wallet-signed request the way it already accepts an API key. Drop it in, point it at an InsumerAPI key, and a caller can authenticate by proving its wallet meets a condition instead of presenting a bearer secret. This is additive, not a replacement. Existing API-key callers keep working byte for byte; wallet-signed callers get a second door. Most adopters will run both forever.

We use that second door ourselves. An agent that buys credits with USDC on Base is also minted a wallet-bound Insumer Access pass, and can then authenticate to /v1/attest by signing with that wallet rather than carrying a key in a header. The transaction sender wallet is the identity. The payment is the authentication. No email, no human in the loop, and no static string sitting in a config file waiting to leak. The free key path still exists; the pass is one more way in, not a gate in front of the others.

The whole lifecycle, one agent

Here is where the two audiences turn out to be one design. Follow a single agent through a full arc, and watch how few of the pieces are new.

The agent arrives at a merchant. It proves a condition to get in the door, the same read a human shopper triggers at the counter. It checks whether its wallet qualifies for a discount tier through /v1/discount/check, the same calculation that prices a shopper at the register. It pays, and confirms its own payment landed on chain through /v1/payment/confirm. When its credits run low, it tops itself up and keeps going, no human anywhere in the loop. Every step is the primitive: read wallet state, evaluate a condition, return a signed result. The discount tier, the entry decision, the payment confirmation, the credit refill. Different questions, identical shape.

None of those steps carries a secret the agent could lose. There is no API key to leak, no password to phish, no session token to replay tomorrow. The agent does not hold a proof. It requests a verdict, fresh each time, signed, verifiable by anyone who reads the public key. We built the workbench to make this composition visible, an endpoint map and a set of reference patterns showing how the calls snap together into real flows. Read, evaluate, sign. The blocks compose because they were always the same block.

People get a discount for what they own. Agents get through the gate without a secret. It is the same read underneath.

Two audiences, one primitive

We did not build a product and then look for users. We built one small primitive and arranged it for whoever showed up. People showed up at the cash register, wanting their holdings to mean something at checkout. Agents showed up at the API gateway, needing to prove what they control without carrying a secret. The arrangements look different. A QR scan and a stablecoin-paid session do not resemble each other. Underneath, they are the same three verbs.

That is what we have built. A primitive that is in production, a set of free tools for merchants and shoppers, packaged products for publishers and shops, a gated room for agents, and middleware that gives any API a wallet-signed door. None of it is a roadmap. It responds today.

The internet was built around secrets because humans needed secrets. The next decade is being built for software that does not, and for people who would rather prove what they own than hand over everything they are. We built for both. They both sign.

Douglas