A founder note on what changes when software starts paying for itself.
Three curves are converging right now. Most people see them separately. The interesting moment is what happens when they cross.
The first curve is agentics. Software is becoming an autonomous economic actor. It is no longer a tool a human picks up and uses for a few minutes at a time. It is a process that runs continuously, makes decisions, signs in to services, holds assets, talks to other software, and pays for what it consumes. Gartner expects roughly a third of enterprise applications to include agentic AI by 2028, up from less than 1% in 2024. By the same year, about 15% of day-to-day operational decisions will be made autonomously. Anthropic and OpenAI have both shipped agent tooling in the last twelve months. Coinbase, Mastercard, and Visa have all announced agent payment infrastructure. The picture is no longer hypothetical. Software is starting to spend money.
The second curve is tokenization. Real-world rights are moving on chain. Memberships. Tickets. Access. Loyalty. Identity attestations. And, finally, equities. Larry Fink, who runs the largest asset manager on earth, has said publicly that every stock and bond will eventually be tokenized. BCG and ADDX put tokenized assets at $16 trillion by 2030. Standard Chartered's projection is $30 trillion by 2034. McKinsey's base case is more conservative but still in the trillions. What matters is direction, not exact magnitude. The thing happening underneath these numbers is that ownership, which used to live in a database that a bank ran, is moving to a wallet that a person, or a piece of software, can carry.
Equities are starting to land in your pocket. They will arrive at the point of sale.
The third curve is cryptographic pressure. The internet's authentication layer was designed for a world in which software was supervised, identities were human, and secrets could safely live for years. That world is ending. Passwords are now cracked by graphics cards faster than most people can read a sentence. Hive Systems' annual brute-force benchmark, updated this year, shows what a single high-end GPU can do to an eight-character password in minutes. API keys leak by the millions. GitGuardian found nearly thirteen million new secrets in public GitHub repositories in a single year. Verizon's 2024 breach report concluded that stolen credentials are involved in roughly a third of all breaches. And out at the horizon, Google researchers published work this year showing that fewer than a million qubits could derive a private key from a public one in a matter of hours. The U.S. Federal Reserve has published research on "harvest now, decrypt later" attacks against blockchain networks. The threat is real. The timelines are debated. But the architectural verdict is in. Any system that depends on a single long-lived secret to control access will eventually fail.
These three curves are intersecting at one place: the authentication layer of the internet.
The internet was built for humans
Look at what we type in when we log in to something today. A username. A password. Sometimes an email link. Sometimes a code from a phone. The whole user-experience surface of authentication is built around the assumption that a human is at the keyboard, that the human can be challenged, that the human can be trusted to remember a secret, and that the system can punish the human if the secret leaks.
It worked. For thirty years it worked.
But every assumption in that sentence is wrong when the user is not a human. Software does not remember secrets. Software cannot be challenged with a CAPTCHA. Software cannot be punished. Software does not have an email address that anyone owns. Software does not have a phone. And when software is the customer, every old auth pattern starts to glitch.
API keys were the first patch. Give the software a long string. Treat the string as a secret. The string proves the software is who it says it is. Hope nobody copies it. It is, structurally, a password. With all the same fragility.
Passkeys are a newer patch, beautiful in their way, but still a patch on the same shape. There is a secret. The secret moves. The secret is harder to phish. But there is still a secret. And the secret is still the trust anchor.
The honest read is that we have been building extensions of the password for a long time, and the extensions keep needing new extensions, because the underlying primitive does not fit a world in which the user is not human, the user holds tokenized value, and the attacker is a model that runs eight hundred phishing campaigns in parallel for fifty cents.
The collision
When the three curves intersect, here is what happens.
Agents start showing up at the checkout, at the API gateway, at the gated event, at the trading interface. They arrive with wallets that hold tokenized equities, fan tokens, memberships, stablecoins. They want to transact. They want to enter. They want to claim a discount they qualify for. They want to prove a condition without telling the verifier their whole history. They want to walk into a system, do one thing, and leave.
And the merchant, the API, the venue, the broker, the platform, all want to know one thing. Are you allowed in?
In the old internet, that question was answered with a password. Sometimes a token. Sometimes a card. Always a secret of some kind, sitting somewhere, waiting to be stolen.
In the new internet, the answer is a signed proof.
That is the sentence the rest of this essay is about.
I have spent twenty years in traditional finance and seven in blockchain. A decade at Morgan Stanley. FX prop trading at Merrill. Helping run the first registered security IPO on the blockchain. Five books along the way about how this technology actually changes the plumbing of money. I have watched every major reorganization of the financial internet from the inside, including a few I helped run, and I have learned to recognize when a curve has stopped bending and started snapping into place.
This is one of those moments. Agentics is not a feature. Tokenization is not a sector. Cryptographic pressure is not a security beat. They are the same story, told from three different rooms, and the audience for what gets built next is not the audience we have been building for. The customer of the next decade is a piece of software with a wallet, transacting on behalf of a human who never logs in. That is the audience this essay is about, and the audience our product set was built to serve.
The internet is moving from passwords to proofs
OAuth, the protocol that lets you sign in to one service with another, was the last great accommodation the internet made for human identity. It said: instead of giving every service a password, give one service the password, and let the others read a signed assertion from it. Sign in with Google. It was a real improvement. It moved the burden off the user.
Wallet auth is the next accommodation, but for a different shape of user. Where OAuth proves who you are, wallet auth proves what you hold, what you control, and what conditions you currently meet.
The mechanism is simple to describe, even if it is not simple to build. A wallet exists on a blockchain. The blockchain already holds the truth about that wallet. Its balances, its memberships, its on-chain attestations, its history of compliance checks, its membership in a curated registry. None of this is hidden. None of this is owned by us. It is just there. We read it. We evaluate it against the condition the verifier cares about, in the moment. And we return a signed boolean. Yes, this wallet meets the condition. Or no, it does not.
The signed boolean expires in thirty minutes. Not because we wanted to invent another expiry timer, but because wallets are fluid. Assets move. Conditions change. A proof about a moving target should not outlive the moment it was true. There is no long-lived secret. There is no token the agent can leak. There is no string the attacker can replay tomorrow. The proof was true at 2:47pm on a Tuesday, and at 3:17pm it is worthless.
Three properties fall out of this design that matter to the world we are walking into.
The first is that ephemerality kills harvest-now-decrypt-later. There is nothing valuable to harvest. A collection of expired booleans is not a back door to anything.
The second is that the signature is swappable. We sign attestations today with the same algorithm family that secures most of the modern web. If quantum cryptography forces a migration to a post-quantum scheme, we rotate the signing key, publish the new public key to our public JWKS file, and update the algorithm identifier. Every verifier that reads our JWKS picks up the new key automatically. There is no hard fork. There is no coordination across thousands of nodes. There is one deployment.
The third is the one that makes this work for autonomous software. Because the proof is not a thing the agent carries, it is a verdict the agent requested. The agent has no secret to lose. It just keeps asking the question. Am I allowed in? And the answer keeps coming back, signed, fresh, verifiable offline by anyone who has the public key.
The internet is moving from passwords to proofs. The interesting part is what that lets us build.
You only need to show you are twenty-one
There is a second design problem buried inside the first, and it is bigger than most people realize.
Almost every authentication system on the internet today is built around oversharing. To prove you are old enough to be in a bar, you hand a bouncer your driver's license. The license shows your address, your weight, your eye color, your full date of birth, your organ donor status, and a photograph that has been on file in a government database for a decade. The bouncer needed one bit of information. You disclosed forty.
That bargain was acceptable when the bouncer was a human in front of you and the data went back into your wallet. It is not acceptable when the verifier is a software system that will retain everything you handed it, store it in a database that will eventually be breached, sell it to a marketing partner you have never heard of, and surface it five years from now in a context you cannot predict. The leaked-credential statistics earlier in this essay are not separate from the privacy question. They are the privacy question. We over-disclose. The system stores what we disclosed. The system loses it.
The blockchain world inherited the same problem in a different costume. Every public block explorer in the world will, for free, show you the entire contents of any wallet you point it at. Total balances across every token. Every transaction the wallet has ever made. Every counterparty it has ever interacted with. The crypto-native answer to is this user a holder? has historically been let us look at the whole wallet. That is the same handbag the bouncer is asking you to open. The fact that the data is technically public on the chain does not make the oversharing pattern any less wasteful, and it does not make the user any less exposed.
The law is moving against this. The EU's age verification framework, rolling out across member states this year, is structured specifically so that an adult website never sees the user's identity, only a signed yes-or-no. Louisiana, Texas, Utah, and a growing list of US states have passed equivalent laws for the same use case. The European Data Protection Board has issued formal guidance on blockchain transparency and personal data, because chain-public is not the same as consent-public. The GDPR's data minimization principle, written in 2016 before any of this hit the consumer internet, says verifiers should request the minimum information necessary for the purpose and no more. The regulators are converging on the same insight the cryptographers reached a generation earlier. Show less. Prove more.
This is what the signed boolean was built to do. The verifier asks a question. The primitive returns yes or no. It does not return the balance. It does not return the chain. It does not return the wallet's history, its other holdings, its counterparty graph, or its trust profile. It returns the bit of information the verifier actually needed, signed and dated, and nothing else. The user proves they qualify without disclosing what they own.
You do not show everything in the handbag. You show proof you are twenty-one.
What we built
We have spent the last two years building the primitive underneath that sentence. The result is InsumerAPI, live in production today. It reads wallet state across thirty-seven blockchains, evaluates conditions, and returns ECDSA-signed results that anyone can verify against a public key we publish at a standard, stable path on the site at insumermodel.com/.well-known/jwks.json. There is no opacity in this. The signing key is public. The condition is hashed and embedded in every proof so a verifier can confirm the question was not altered. The signed boolean is the entire payload. You can verify everything offline. You can do it right now.
We did not start with products. We started with the primitive. The primitive is small enough to describe in one sentence. Read on-chain state, evaluate it against a condition, return a signed result. Everything else is composition.
The endpoint surface follows that shape. There are seven groups, and you do not need to be a developer to understand what each one is for.
Verification is the heart. /v1/attest takes a wallet and a condition and returns the signed yes-or-no. It does the read, the evaluation, and the signing in one call. /v1/verify is the offline counterpart, which lets a verifier hand a previously-issued attestation back to the API for a structural check.
Trust is the multi-dimensional view of a wallet. /v1/trust returns a profile across eight dimensions, things like age, activity, on-chain behavior patterns, and provider attestations. /v1/trust/batch does the same in bulk. Where Verification answers one question about one condition, Trust paints a picture of the wallet's overall posture.
Commerce is where wallet state meets the cash register. /v1/discount/check returns a signed discount tier the wallet qualifies for in the moment. /v1/payment/confirm confirms that a crypto payment to a merchant landed on chain and matches the expected amount. /v1/codes/{code} lets a merchant validate a one-time code without exposing how it was generated. /v1/acp/discount and /v1/ucp/discount are the protocol-shaped versions of the discount call, designed for agent commerce protocols that want a wallet-state response in their native envelope.
Compliance is the lookup that returns approved condition templates a merchant or platform can drop into a flow. /v1/compliance/templates exists so a verifier does not have to invent its own conditions for accredited-investor checks, geographic eligibility, or sanctioned-address screening.
Merchants is the operational shell around the primitive. A merchant onboards, configures which tokens or NFTs it cares about, verifies its domain, publishes itself to the directory, and tracks its credit balance.
Account is for the people and the agents holding API keys. /v1/keys/buy and /v1/keys/purchase create keys. /v1/credits reports balance. /v1/credits/buy tops up. A small thing worth noticing here: an agent that pays for itself in stablecoin can refill its own API credits without a human in the loop. The API is structurally agent-payable. Most APIs are not.
JWKS is the one endpoint that is not really an endpoint at all. It is a public file at insumermodel.com/.well-known/jwks.json that publishes our verification key. This is the audit surface for the entire system. Anyone with that file can verify any attestation we have ever issued, offline, forever, without making a network call to us. A compliance officer reviewing a past transaction. A regulator reconstructing what an agent did inside an AgentTalk session. A counterparty checking whether a signed claim was actually ours. A buyer six months from now asking why a discount was granted. All of them can pull the file and walk the cryptographic chain back to the moment the proof was issued. We do not control what gets verified or when. We just publish the key, and the key stays published. Years from now, the receipts will still check out.
That is the API. None of it is glamorous on its own. The point of the primitive is that it is small enough to combine.
None of what I just described is a roadmap. The API has been processing real attestations for live merchants and platforms across thirty-seven blockchains since launch. The JWKS file is publicly fetchable. Any attestation we have ever issued can be verified against it, offline, today. The endpoint paths above are not aspirational. They respond.
Products are manifestations of the primitive
When you have a primitive that small, products are not separate inventions. They are arrangements. We built three of them under the SkyeMeta brand to make the primitive consumable for people who would never want to call an API directly, plus one piece of free open-source middleware for developers who want to wire it into their own stack.
The first is SkyeGate. SkyeGate gates content. A founder who runs a member site, a creator with a research portal, a small studio publishing premium docs, all of them used to enforce access with a password and a payment processor. SkyeGate replaces that with a wallet read. A reader connects a wallet. The site asks InsumerAPI whether the wallet meets the condition the publisher set. The signed answer comes back. The page renders, or it does not.
What is unusual about this is what the page itself looks like. The URL is public. Anyone can visit it. The HTML envelope is indexable by search engines. But the gated content does not exist in the rendered page unless the wallet meets the condition. A reader without the right wallet sees nothing. A developer who opens browser devtools sees nothing. There is no hidden field to inspect, no API token to scrape, no admin URL to brute. The sensitive material sits behind a wallet read and is invisible to anyone who cannot satisfy the condition. Secrets in plain sight, on an open page, on the open web.
There is a free tier that ships as a WordPress.org plugin and a paid tier at $49 a month that adds stacked rules, more chains, and a Vercel/Next.js SDK for sites that do not run WordPress. The same license key works on either stack.
The second is SkyeWoo. SkyeWoo is the same idea pointed at WooCommerce checkouts. A merchant running a shop on WordPress can offer wallet-verified discounts to holders of a particular token, members of a particular DAO, or holders of an NFT collection, without managing those lists by hand. The discount tier appears at checkout because InsumerAPI returned a signed proof that the shopper's wallet met the merchant's condition. $49 a month, same license shape as SkyeGate.
This is the surface that begins to matter as tokenized equities arrive in wallets. The shopper standing at the point of sale, in person or online, is increasingly going to have on-chain assets that say something about them. A long-term holder of the merchant's own token. A holder of a tokenized membership. A holder of a tokenized equity in a partner brand. A holder of a tokenized loyalty NFT issued by the merchant's parent group.
Walk into an Apple store holding tokenized Apple shares. The wallet read happens at checkout. The discount appears. Walk into a Ford dealership holding tokenized Ford. Same flow. Same proof. Same kind of discount. The merchant is no longer giving the shopper a perk for being a loyal customer. The merchant is recognizing that the shopper already owns a piece of the company. The pattern works for any brand whose equity is tokenized. Which is to say, eventually, every brand.
The CFO line on this is sharper than the marketing line. Traditional membership rewards are an accounting liability. Every point a loyalty program issues sits on the balance sheet as something the company owes the customer. Discounts based on share ownership are not a liability. The customer already owns the upside. The merchant is acknowledging that, not creating new financial obligation. For a CFO trying to retire a points program that has quietly become a billion-dollar overhang, replacing it with a wallet-read discount for the company's own shareholders is the cleanest possible swap. The CMO gets a loyalty program. The CFO gets the liability off the books. The shareholder gets a tangible reason to hold.
None of this is hypothetical anymore. The cash register learns to read the wallet. The wallet learns to surface the asset. The merchant learns to price for the relationship. We built the part underneath that lets the wallet read be trustworthy and signed, so the merchant is not taking a stranger's word for what the wallet holds.
The third is AgentTalk. AgentTalk is a condition-gated communication surface for AI agents. We call it a SCIF for agents, because the closest analogue in the human world is a sensitive compartmented information facility, a room a human can enter only after meeting a specific clearance condition. AgentTalk is the same idea for software. An agent walks up to a session. The session checks the agent's wallet against a condition. If the agent qualifies, it enters and can communicate with the other agents in the room. If it falls out of qualification mid-session, it gets ejected.
AgentTalk scales. The same primitive that gates a two-party negotiation gates a town hall. There is no maximum number of agents in the room. A protocol DAO running a governance call with two thousand agent voters, each of whom must hold a particular governance token, is the same shape of session as a private trade between two market makers. The condition is checked on entry. It is checked again during the session. Membership is fluid. Whether five agents are in the room or five thousand, the architecture is identical. There is no admin dashboard for a human, because the customer is not a human. The agent pays in stablecoin credits, drawn down per interaction, and refills itself when its balance runs low. This is the product that exists because the curves are crossing. A year ago this product would have been a deck. Today it has paying agents in it.
Between the packaged products and the bare API sits one more piece of infrastructure worth naming. @skyemeta/access is open-source middleware, MIT-licensed, free to use. It turns any API into one that authenticates by wallet auth instead of by bearer token. A platform operator installs it, points it at their InsumerAPI key, and from that moment any agent or user calling their API just needs to prove their wallet meets the condition the platform set. No API key issuance flow. No bearer secret to leak. No revocation list to maintain. If the wallet stops qualifying, the next call fails. If it keeps qualifying, the next call keeps working. It is the cheapest possible way to turn a normal API into an agent-payable one without leaving a single static secret behind.
The next surface, SkyeProfile, is the one that comes after. It is the multi-dimensional wallet trust profile, the consumable form of the /v1/trust endpoint, packaged for agents and platforms that need a fast overall read on a wallet before they decide to transact. It is already orchestrating ten issuers underneath, each contributing a different facet of the wallet's posture, so a verifier asking the profile for an answer gets a true cross-issuer fingerprint and not a single-source opinion. It has a marketing page. It is not yet for sale. The orchestration is shipped. The storefront follows when the market shape is ready.
Different products. Same primitive underneath. We could keep building them. So could anyone else.
The workbench
The thing we underestimated when we started was how much of the value lives in the combination of these endpoints, not in any endpoint alone.
A merchant who wants to offer a price tier to wallets that hold a particular tokenized equity, and meet a geographic eligibility template, and have a trust profile above a threshold, is asking three questions at once. In the old internet, that flow would be three integrations with three vendors and a lot of glue code. With wallet auth, it is three calls that compose into one signed verdict. Read, evaluate, sign. The blocks just snap together.
We built the workbench to make the snapping visible. It is a visual map of every endpoint on the API and seventeen reference patterns that show how those endpoints combine into real-world flows. A loyalty program. A compliance gate. A discount tier at point of sale. An agent-payable API. A continuously re-verified agent session.
The workbench exists because we believe the world that is coming is one in which any business, any platform, any agent operator should be able to assemble a verification flow without building a verification stack. You do not need to know how blockchains work to draw the line between check trust, apply discount, and confirm payment. The blocks are there. They are signed. They are public. They compose.
That is what the workbench tells you, in one screen.
Who this is for
The audience for this is not crypto people. It is everyone whose business depends on knowing whether someone is allowed in, and who is starting to suspect the password is the wrong tool.
It is the small business owner who wants to offer a loyalty discount to holders of a particular token without building a database and a fraud-detection layer to defend it.
It is the platform operator whose API is about to start being called by agents that pay for themselves, and who needs an authentication shape that does not assume a human at a keyboard.
It is the compliance team that needs to enforce eligibility templates without storing identity files they will eventually be breached holding.
It is the token community that has spent five years issuing assets people could hold but not use, and now wants to make the holding mean something at the checkout.
It is the brokerage and the asset issuer watching tokenized equities migrate into self-custodied wallets, who need a way for a counterparty to verify a holding without seeing the whole portfolio.
It is the shopper walking into an Apple store with Apple stock in their wallet, who is about to discover that a brokerage app and a loyalty card are no longer different objects.
It is the CFO whose membership-rewards program has quietly become a billion-dollar liability on the balance sheet, who realizes that a wallet-read discount for the company's own shareholders is the same product without the accrual.
It is the agent operator who has built an autonomous workflow and needs that workflow to prove what it controls without carrying around a leakable secret.
It is the regular person who has reset their password seventeen times this year and is starting to wonder whether the password should still exist.
They sign
We do not think every password disappears tomorrow. We do not think every API suddenly becomes wallet-native. There will be passwords in five years and ten years and probably in fifty years, the way there are still fax machines.
But the next generation of autonomous software will authenticate differently than humans did, because the assumptions humans needed do not apply. Software does not need a secret. Software has a wallet. The wallet's state is already public. The verifier just needs to read it, evaluate it, and trust the signature on the answer.
The internet was built around secrets because humans needed secrets.
Agents do not.
They sign.
Douglas