How InsumerAPI Powers SkyeGate Lite

SkyeGate Lite is now live on WordPress.org. It runs on InsumerAPI. The primitive is wallet auth: read, evaluate, sign. Boolean, not balance. Verified yes or no. This is what InsumerAPI provides, and what a product like SkyeGate stands on.

Wallet auth, defined

Wallet auth is to a wallet what OAuth is to an account. It is a primitive for proving access. The difference is what it proves. OAuth proves who the user is. Wallet auth proves what the wallet holds.

A caller sends conditions. A token balance threshold. An NFT held. An EAS attestation present. A chain of these, combined into one boolean. InsumerAPI reads chain state, evaluates the conditions, and signs the verdict. The response is one boolean per condition.

Verified yes or no. Boolean, not balance.

What the signed verdict carries

Every verdict from InsumerAPI is an ES256 JWT. ECDSA over P-256, the same cryptographic shape used in modern web standards. The payload is short. Pass or fail per condition. A condition hash for tamper detection. An expiration. The issuer (https://api.insumermodel.com). A signing key identifier (insumer-attest-v1).

The signing key is published at https://api.insumermodel.com/.well-known/jwks.json. Anyone can fetch it. Anyone can re-verify any verdict, end to end, without asking InsumerAPI again.

Three properties products inherit

A product running on InsumerAPI inherits three things by virtue of using the primitive.

• Deterministic. Same wallet, same conditions, same chain state. Same verdict. No model drift. No scoring opinion. No judgment call.
• End-to-end verifiable. The signature is from InsumerAPI, not from the product. A product cannot forge a pass even if it wanted to, because anyone can re-verify the JWT against the public JWKS endpoint.
• No consumer secrets in the loop. The primitive does not accept and cannot use consumer credentials. There is nothing to phish, rotate, store, or leak.

A product like SkyeGate gets all three properties by design, not by discipline.

No secrets, no identity-first, no static credentials

This is the narrative core. A visitor connects a wallet and supplies a public address. That is the entire input on the consumer side. There is no password. No email. No API key on the consumer side. No shared secret between the merchant and the customer. There is no identity claim at all. Only what the wallet holds.

The merchant inherits this property automatically. A merchant running on InsumerAPI cannot accidentally introduce consumer-secret leakage, because the primitive does not accept consumer secrets to begin with. The failure mode wallet auth removes from the surface is the failure mode every credential-based gate suffers from. Storing consumer secrets that someone, somewhere, eventually leaks.

Provable and private

Both properties have to coexist or the primitive does not work.

Provable. A merchant or end user can take any verdict and re-verify it against the public JWKS using only public information. The verdict cannot be forged. The condition cannot be silently changed, because the condition hash catches it. InsumerAPI itself cannot rewrite history, because the signature pins the verdict to the moment it was issued.

Private. The verdict is a boolean. It does not say how much is in the wallet, what else is held, who the user is, what other addresses they control, or what they have done. A merchant gating ETH at a 0.1 threshold learns yes or no. Not the balance. Not the wallet history. Not the identity. Boolean, not balance.

Provable and private.

Condition-based access, one primitive, many surfaces

SkyeGate is one product on top of the primitive. It runs on WordPress.

The same primitive also slices. SkyeGate Lite, the free WordPress plugin, exposes one condition per gate. SkyeGate, the paid version, exposes up to ten conditions chained into one boolean. Both run on the same /v1/attest call. The primitive does not change. The product chooses the slice.

The same primitive runs other surfaces too. SkyeWoo gates WooCommerce. AgentTalk handles agent-to-agent calls. Same boolean, same JWKS, different transport. Any HTTP-speaking client can call /v1/attest, get back a signed verdict, and gate whatever it gates.

The primitive scales sideways. New surfaces do not require a new primitive. They require a new consumer of the same primitive. A signed boolean is portable.

Try it

SkyeGate Lite is free on WordPress.org. The SkyeMeta announcement walks through install and the first shortcode.

Or build your own consumer. POST conditions to /v1/attest, verify the returned JWT against the JWKS endpoint, and gate whatever your stack gates. The full reference is at /developers/api-reference/.