Live demo · PortaldotV3 testnet · test tokens only

Buy a real API call from this page.

No wallet, no install. A public test key in this page signs a voucher against a capped prepaid session, the hosted seller checks it and answers. Nothing goes on-chain per request: the seller settles many requests in one transaction, in Solidity and ink! together, and each batch carries a signature from the session key over the requests made and the responses received. Test tokens only.

Buy one request

0.01 pUSD per call · endpoint 3
    
            
    1. HTTP 402. The seller quotes 0.01 pUSD for endpoint 3.
    2. A voucher, signed here. Your browser signs it with the page's public test key: no gas, no wallet.
    3. HTTP 200. The data arrives with a provider-signed receipt, and its hash is checked.
    4. Settled later, in bulk. The seller redeems this request with many others in one Ethereum transaction, listed in the batches table.

    The public session, live from the seller

    blockrequests settledsessionsone Ethereum tx
    loading…

    What one request costs on-chain

    per-request escrowprepaid session
    on-chain transactions, 1 request2: pay, then settlenone: a voucher signed over HTTP
    on-chain transactions, 100 requests2003: open, one settlement batch, close
    locked for good per request7.53 tPOT0.076 tPOT, in a 100-request session
    locked for good, 100 requestsabout 753 tPOT7.6 tPOT

    Measured on this testnet with our own keys, blocks 276657 to 276660 and 282559. Test tokens have no value; the ratio is the point.

    Check it against the chain

    Replays the seller's public log of this session against the payer-signed head in each Redeemed event on the EVM and its ink! anchor on the WASM VM.

    Two ways to pay

    Per-request escrow, and prepaid sessions

    An API provider lists an endpoint with a price. A client pays for one request in an ERC-20 (here a Portaldot native asset, reached through the pallet-assets ERC-20 precompile). The payment waits in escrow in a Solidity contract on Portaldot's EVM. The provider settles it once it has served the request, or refunds it. An ink! registry on Portaldot's WASM VM keeps the provider's public record. Everything on this page is read live from the testnet by your browser.

    1. 1GET, then a 402 quote
    2. 2pay() on EVM
    3. 3retry with signed proof
    4. 4served once + receipt
    5. 5settle + ink! record, one tx

    That is the escrow path, for calls worth a few cents or more. High-frequency APIs use a prepaid session: one budget, a signed voucher per request, many requests settled in one transaction.

    Demo video, 2:23

    The measured cost problem, a real call bought from this page, block 282559 settling 137 requests in one transaction, the log replayed against the chain, and the escrow path. Watch on YouTube or download the MP4 (7 MB).

    Network

    Contracts

    status
    loading…

    Payment token: a native asset seen as an ERC-20

    Two test assets, one per payment path. The prepaid sessions and the hosted seller (endpoints 3 and 4) are priced in pUSD, asset 7777, Portaldot's own test dollar. The per-request escrow run (endpoints 1 and 2) used tUSDm, asset 43907 "Portal Meter Test USD", which we created for it; that is the asset read below.

    Portaldot exposes every pallet-assets token to Solidity at 0x{asset id}…00010000. The supply below is read twice: once through the EVM (totalSupply() on the precompile) and once from Substrate storage.

    Endpoints and provider record

    Price and payee come from MeterSettlement (EVM). The URL and the served / refunded / confirmed / disputed counts come from MeterRegistry (ink!), keyed by the provider's EVM address. On a session endpoint, one "served" is one anchored batch of many requests. A score shows only once a payer has confirmed a request. Endpoints 1 and 2 were listed by our escrow test run against a seller on our own machine: their on-chain URLs are kept as recorded and cannot be reached. Endpoints 3 and 4 are the public sellers.

    #endpointpriceproviderservedrefundedconfirmeddisputedscore
    loading…

    Escrow activity

    Every Paid, Served and Refunded event of MeterSettlement, in tUSDm. What was paid into escrow is either settled to the provider or refunded to the payer, so the first amount is the sum of the other two. Session requests settle through MeterSession and are counted in the buy box above.

    blockeventrequestamountdetailtx
    loading…

    Verify a receipt

    Paste the PAYMENT-RESPONSE header (base64) or the receipt JSON. Add the response body to check its hash. Nothing leaves your browser except read-only calls to the Portaldot testnet nodes.

    Deployment transactions

    steplayerblocktx
    pending