01 Verify directly from your agent
The SDK reads Arc directly. It does not rely on the PayTLS API or database for authorization.
import { PayTLS } from "@paytls/sdk";
const paytls = new PayTLS({
rpcUrl: process.env.ARC_RPC_URL!,
registryAddress, // deployed PayTLS registry
});
const result = await paytls.verifyPaymentRequest({
url: serviceUrl,
paymentAddress: payment.payTo,
signingKey: payment.signingKey,
});
if (!result.valid) throw new Error(result.reason);
await sendPayment();Verification authorizes credentials; it does not validate a payment-request signature. The included agent integration validates signed quotes separately and rechecks authorization immediately before transferring USDC.
02 Prove the domain. Authorize the credentials.
- Connect your wallet and sign in.
- Enter a DNSSEC-enabled service domain.
- Publish the generated TXT record at
_paytls.your.domain. - Verify DNS, configure the payment address, signing key, route, and expiry.
- Submit the proof and certificate in a wallet transaction on Arc.
The contract validates the complete DNSSEC chain and consumes the challenge. A replacement revokes the previous certificate for the same domain. Challenges expire after 24 hours; certificates last up to one year.
Open domain management03 Hosted verification API
GET /api/v1/verify?domain=api.your.domain&payTo=0x…Add signingKey to check a signing address and url for route-scoped certificates. The SDK uses the same rules without requiring this endpoint.
| Result | Agent behavior |
|---|---|
| valid: true | Credentials were authorized at the returned block. |
| status: invalid | Refuse payment. Inspect the machine-readable reason. |
| status: unavailable | Refuse payment and retry later. |
The public registry explorer uses GET /api/v1/registry with domain for a live onchain lookup, address for an indexed wallet search, or no parameter for recent registrations. It is for discovery; agents still verify before paying.
04 What PayTLS proves
A wallet authorized payment credentials for a domain through a valid DNSSEC proof at issuance. The certificate is currently unexpired and unrevoked at the checked Arc block.
DNSSEC depends on the DNS root, registrars, domain operators, and their signing keys. Arc supplies the public state and history. Your chosen RPC must accurately report that state.
Proves
- DNSSEC control of the exact domain at issuance
- The current recipient, signing key and route scope
- Unexpired and unrevoked at the checked block
Does not prove
- Service honesty or response correctness
- Value for money or freedom from compromise
- Ongoing domain ownership after issuance
Verification and payment are separate transactions; revocation can occur between them. Only supported signed DNS chains can issue. Removing the TXT record does not revoke a certificate. Use the owner wallet to revoke onchain; a new DNS owner can prove control and replace the domain’s certificate.
05 A real 402-to-USDC flow
The included research endpoint returns a signed, five-minute payment quote. The agent validates it, checks the current registry, transfers 0.01 USDC, then redeems the receipt with a payer signature. The service verifies settlement on Arc and prevents reuse across requests.
This is an x402-style direct-settlement example, not a claim of full x402 wire-protocol compatibility. A service signing key, funded payer, deployed registry, and controlled DNSSEC domain are required.
06 Frequently asked questions
What does a PayTLS certificate prove?
That a wallet authorized payment credentials for an exact domain with a valid DNSSEC proof at issuance. Verification then checks that the current certificate matches the request and is unexpired and unrevoked. It does not guarantee service quality or ongoing domain ownership.
Do agents need to trust the PayTLS website?
No. The TypeScript SDK reads the registry directly from Arc without the PayTLS API or database. It relies on the configured registry, Arc consensus, and an RPC that reports chain state accurately. Use a trusted RPC or your own node.
Why DNSSEC instead of a normal TXT record?
An unsigned TXT record can be spoofed and proves nothing onchain. DNSSEC signatures chain up to the IANA root, so the contract can verify them itself. Unsigned zones and unsupported algorithms fail closed.
What happens when payment credentials change?
Issue a replacement with a fresh DNSSEC proof. It atomically revokes the previous certificate for that exact domain. You can also revoke outright from the owner wallet. Revoked records remain public and inspectable.
Does PayTLS send payments for my agent?
No. The SDK verifies authorization and your application controls payment. The included agent example validates a signed quote, rechecks the registry, transfers 0.01 USDC on Arc and redeems the receipt. It is x402-style direct settlement, not full x402 wire compatibility.
Why Arc?
Agents need a public registry they can read without trusting PayTLS, that PayTLS cannot silently rewrite, and that keeps history. Arc settles USDC natively with EVM execution, so certificate state lives next to the payments it protects.