Skyfire / KYA Pay: Identifying an Agent and Its Payer

Agent identity, payments and service discovery · Sources checked October 28, 2026. Public-source analysis; we did not register or make a test payment.

A research agent needs a search API. The API requires not just payment but information about which company the buyer represents and which identity fields the service requires. Skyfire brings identity claims, service-specific payment credentials and a service directory into one interaction. It is more than a downloadable multichain wallet: accounts and wallets are parts of a wider service network.

Background and product position

KYA, or Know Your Agent, concerns identifying an agent and the person or company behind it; KYA Pay extends this to payment credentials. Skyfire also provides platform examples, APIs and a service directory. It describes programmatic service procurement without repeating conventional website registration and payment for every service. The KYA Pay whitepaper describes Skyfire’s implementation and workflow; it does not establish that all KYA-compatible parties rely on the same wallet. See also the project overview.

How might a purchase work?

This example follows the published workflow and was not tested by AgentWallets.

The provider says a buyer can fund its wallet by card, USDC or ACH; sellers specify required identity fields. A buyer creates a service-specific pay, kya or combined token. The seller verifies it, provides the service and then calls an API to charge all or part of the amount. This sequence follows the whitepaper example; delivery and charging conditions depend on the service contract and integration. See the whitepaper and service discovery.

Capabilities and boundaries

KYA verification is described as optional, but sellers can demand a verification level; a buyer who does not qualify may not be able to create the relevant token. Optional verification does not mean every seller accepts anonymous buyers. See KYA guidance.

Business model and competition

The verification guide states that KYA verification requires a subscription, with personal and business plans, but does not give a verifiable specific price on that page. Funding, withdrawal and transaction fees require checking the current contract and pricing; the existence of a subscription does not prove a fixed transaction fee. Skyfire may be able to charge for identity, service access or transactions, but a revenue breakdown was not disclosed in the reviewed materials.

Compared with Nevermined, Skyfire’s public materials particularly emphasize identity claims, discovery and service-specific tokens; Nevermined also highlights usage metering, service pricing and authorization. Compared with x402, Skyfire’s identity and wallet services address a broader business workflow. Whether they can be combined depends on the actual integration.

Teams that need programmatic access to multiple Skyfire-supported services and whose providers need identity or payment signals may find it worth evaluating. Confirm directory coverage, full costs, settlement timing, identity data processing and dispute handling before integration.

What must buyer and seller each do?

A verifiable identity token does not replace the seller’s commercial judgment. A market-data provider must decide price, required identity fields, API interface and when to charge. A listing can include a service ID, minimum payment-token value, OpenAPI or MCP endpoint and terms. The buyer’s developer must create API credentials for its account, check identity requirements and generate a token according to the service specification.

The provider validates the token and parameters, then decides whether to deliver under its own terms. Calling the Skyfire API to charge is a separate action. In the whitepaper example, a seller can charge all or part of a token and funds move between buyer and seller wallets. Permission to buy, service delivery and a seller’s charge are three distinct states; “token created” alone does not establish completion. See service discovery and the whitepaper.

What does identity disclosure cost the buyer?

Verification may reduce repeated onboarding and risk checks for providers, but can increase disclosure of personal or corporate information. Before integration, review which fields are requested, why, which organizations retain them, and whether they can be corrected or revoked. The provider says tokens can disclose fields as needed. This article has not verified privacy protections or established that every seller asks for the same data. See verification guidance.

The official material says some verification failures prevent token creation. If a seller is unavailable or fails to deliver, charging, investigation and dispute handling depend on the implementation and terms. Record token ID, service ID, amount, delivery evidence and charge receipt where available. Developers need to test which fields are actually observable; do not assume the platform automatically supplies complete evidence.

Why is building a network difficult?

Skyfire’s potential value depends on both buyers and sellers joining. Without services buyers need, identity and payment capabilities alone may not create usage; without buyers, sellers have less reason to maintain a dedicated interface. This is a two-sided-network analysis, not a disclosed market-share claim.

A practical evaluation is to list ten required services and ask how many already support tokens, how long integration and identity checks take, and who handles funding, refunds and settlement. Also establish who creates and revokes each buyer agent’s API credential; if it leaks, verify whether an attacker could create new tokens and how existing tokens expire or are revoked. Official information describes separate API keys for buyer and seller agents, but we did not test compromise or revocation behavior.

Sources

• KYA Pay whitepaper: identity, credentials, wallets and charging workflow.
• Service discovery documentation: directory and service metadata.
• KYA verification guide: verification requirements and subscription.