Pay-per-request API pricing becomes a signing problem when a client sees a sample quote for 0.001 ETH, Ethereum’s native token, and needs the amount in the wallet’s accepted token before signing. The client needs the amount in the wallet’s accepted token before signing.
That amount is only the native-token denomination. The provider may accept USDC (USD Coin), the exchange rate may be configured as 3,200 USDC per ETH, the provider may add a 2% markup, and USDC records amounts in six decimal places.
The formula computes the signed integer amount after applying rate, markup, decimals, and flooring. Tangle is a protocol for registering and coordinating services run by independent operators. A Blueprint is a packaged service definition with typed jobs. An operator is the person or service running the paid job. A job is one callable operation in that service. A quote is a time-limited price offer, while a payment is the buyer’s authorization to settle that offer. x402 is the HTTP payment protocol that can carry the accepted-token payment for a job. A facilitator is the service that verifies a signed payment and helps settle it.
Tangle’s public Blueprint SDK keeps the job price in wei, the smallest unit of the native token, and converts it into the accepted token’s smallest unit when it creates a payment option. The current Blueprint x402 configuration exposes the relevant inputs: accepted network, asset, decimals, receiving address, exchange rate, markup, and transfer method.
Convert wei into accepted-token units
For a job quoted in wei, the current public implementation follows this sequence:
- Divide the wei price by 10¹⁸ to express the amount in the native unit.
- Multiply by the configured number of accepted-token units per native unit.
- Apply the operator’s markup in basis points.
- Multiply by the token’s decimal scale.
- Floor the result to an integer smallest-unit amount.
The formula is:
token_smallest_units
= floor(
wei_price / 10^18
× rate_per_native_unit
× (1 + markup_bps / 10,000)
× 10^token_decimals
)Wei is the smallest unit of an EVM native token. Token decimals say how many smallest units make one whole token. Basis points are hundredths of a percentage point, so 200 basis points equals 2%.
Use this sample quote: 0.001 ETH, a configured rate of 3,200 USDC per ETH, and 200 basis points of markup:
sample input: 0.001 ETH × 3,200 USDC/ETH = 3.200 USDC
3.200 USDC × 1.02 = 3.264 USDC
3.264 USDC × 10^6 = 3,264,000 USDC smallest unitsThe buyer sees 3.264 USDC when the token has six decimals. The settlement payload carries 3,264,000 as an integer. The number is an example of the formula, not a current market price or a Tangle fee.
Decimals change the integer representation
The same economic amount can produce different integer representations.
| Accepted token | Decimals | Smallest-unit representation of 3.264 whole tokens |
|---|---|---|
| USDC | 6 | 3,264,000 |
| A token with 8 decimals | 8 | 326,400,000 |
| A token with 18 decimals | 18 | 3,264,000,000,000,000,000 |
The number of zeros does not describe the job’s quality or cost. It describes the token contract’s accounting scale.
Flooring is a deliberate boundary. Blockchains cannot settle a fraction of a smallest unit, so the conversion must choose a rounding rule. Flooring prevents the gateway from asking for an amount the token cannot represent, but it also means tiny jobs can lose a small fraction of the intended price.
An operator should calculate the rounding impact at the smallest supported job price. If a one-unit job becomes zero after conversion, the product needs an explicit free or minimum-price policy rather than hoping a zero amount means the same thing to every component.
For current addresses, use the Circle USDC contract table instead of copying an address from an old example. The table currently lists Base mainnet USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and Base Sepolia USDC at 0x036CbD53842c5426634e7929541eC2318f3dCF7e.
Per-job rates and service-creation pricing
Tangle has a per-job path and a service-creation path.
The per-job path answers, “What should this invocation cost?” The operator supplies a mapping from a service and job index to a wei amount. The x402 gateway converts that amount into the accepted token’s units.
The service-creation path answers, “What should it cost to create this service?” The pricing engine is the operator-side service that generates signed quotes for service creation or per-job work. The public pricing engine guide describes those RFQ modes and the optional x402 settlement fields.
| Pricing model | Commercial unit | Good fit |
|---|---|---|
| PayOnce | One up-front payment when creating a service | A service with a known creation cost and duration |
| Subscription | A fixed amount per billing interval | A service that needs continuing funded access |
| EventDriven | One fixed amount per job or event | A predictable API call or webhook-triggered task |
| Job RFQ | A request-for-quote flow that returns a signed price for this caller and input | Variable compute, model selection, or negotiated work |
The protocol documentation says the pricing model is declared when a Blueprint is registered. Choose PayOnce for a fixed creation cost, Subscription for recurring access, EventDriven for per-event work, and RFQ when inputs change the cost.
An event-driven job rate is easy to explain when every call has a similar cost. An RFQ is better when the input changes the work enough that a fixed number would either overcharge small jobs or undercharge expensive ones.
The Tangle pricing and payments guide describes the fixed, subscription, RFQ, and optional x402 paths together.
Accepted-token configuration sets pricing behavior
An accepted-token entry is more than a currency preference.
It determines where funds move, which chain is used, how the amount is scaled, and how a facilitator transfers the token.
The following is a representative configuration fragment; it omits the deployment-specific pay_to address.
[[accepted_tokens]]
network = "eip155:8453"
asset = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
symbol = "USDC"
decimals = 6
# pay_to is set from the deployment's independently verified operator account.
rate_per_native_unit = "3200.00"
markup_bps = 200
transfer_method = "eip3009"
eip3009_name = "USD Coin"
eip3009_version = "2"The network value uses CAIP-2, short for Chain Agnostic Improvement Proposal 2, a standard way to identify a chain and namespace. The asset is the token contract on that chain. The pay-to address is where the facilitator sends the settlement.
The public Blueprint config validates that the network has an EVM (Ethereum Virtual Machine) CAIP-2 shape, that the asset and receiving address parse as EVM addresses, and that the exchange rate is positive. Those checks are necessary but incomplete. They do not prove that the asset contract exists on the named network, that the receiving address belongs to the operator, or that the operator chose the right wallet.
The network, asset, and receiving address must be checked as a set. Copying a testnet asset into a mainnet network field can pass string validation and fail only when the facilitator tries to settle.
For USDC, the public config source recommends the EIP-3009 transfer method with domain name USD Coin and version 2. EIP-3009 defines transfer authorizations with an amount, recipient, validity window, and nonce. The domain values are part of the signed data, so a mismatch is a payment failure rather than a cosmetic configuration difference.
Markup covers a risk the exchange rate cannot
The exchange rate answers a market question. The markup answers an operator question.
If the operator sets the exchange rate to 3,200 and the markup to 200 basis points, the gateway applies a 1.02 multiplier after converting the wei price into whole token units. Set markup from a defined exchange-rate drift band, settlement cost, failed-attempt allowance, and target margin. It does not make a stale exchange rate current.
Suppose this sample market-rate scenario moves ETH from the configured 3,200 USDC to 2,880 USDC while the config remains unchanged. The sample 0.001 ETH job still produces 3.264 USDC at the gateway. The operator receives a higher token amount relative to the new market rate, while the buyer sees a price that may no longer match the operator’s intended economic value.
Suppose ETH moves to 3,520 USDC instead. The same configured price now produces less market value for the operator. The markup changes the slope by a fixed percentage, but it does not remove the need to refresh the rate.
The current x402 config has a quote TTL with a default of 300 seconds in the public source. The TTL limits how long a caller can rely on the price, but it does not update the exchange rate. An operator running a volatile service needs a rate-source policy, a maximum tolerated drift, and an atomic configuration update with validation, rollback, and failure behavior.
Call this a dynamic price policy. The policy should say who updates the rate, which source they use, how the value is timestamped, what happens when the source is unavailable, and whether existing quotes remain valid.
An RFQ signature makes a quote checkable
An EIP-712 signature is a standard way to sign typed structured data on an Ethereum-compatible network. It lets an independent checker validate the fields that were signed instead of trusting a mutable JSON response. The EIP-712 standard defines the domain and typed-data hashing rules. An evaluation is a repeatable check of whether the resulting job output meets a stated requirement.
In a Tangle RFQ quote, the important fields can include the requester, service or Blueprint, job, price, timestamp, expiry, confidentiality requirement, and input hash. The current pricing and payments documentation explains that job RFQ signatures bind the price to the caller and exact job inputs.
That signature is tamper-evident, not a guarantee of correctness. It does not prove that the operator estimated the cost well. It does not prove that the job result is correct. It does not make an expired quote usable. It does let the contract reject a changed amount, wrong requester, wrong input hash, or reused quote when those fields are part of the protocol’s signed data.
The buyer should retain the quote details alongside the payment record. The following fields are enough to answer “what did we agree to, what did we pay, and what input did that price cover?” without putting private input bytes into the record:
| Record field | What to retain |
|---|---|
| service_id and job_index | The exact callable operation selected |
| price_wei | The native-unit price before token conversion |
| requester | The EVM address bound to the quote |
| inputs_hash | The hash of the canonical input bytes |
| expires_at | The quote’s final acceptable time |
| payment network and asset | The CAIP-2 network and token contract |
| payment amount | The integer smallest-unit amount settled |
| pay_to | The recipient address in the payment authorization |
Proof of work and expiry limit quote abuse
Pricing endpoints can be scraped, used to trigger signing work, or flooded with malformed requests even when later settlement verifies signatures and fields. An attacker can scrape prices, create expensive signing work, or send malformed requests at high volume.
The public pricing engine uses proof of work to rate-limit the GetPrice RPC. The exact request fields are versioned with the pricing-engine service, so use its public schema when constructing a client. The exact difficulty is deployment-sensitive, so an article should not promise a universal solve time.
These controls address distinct failure modes:
| Defense | Failure it addresses |
|---|---|
| Request timestamp and proof of work | Cheap unauthenticated quote spam |
| EIP-712 signature | Mutated price or terms in transit |
| Expiry and quote age | Ancient offers and stale market assumptions |
| Single-use digest | Replaying one signed offer for multiple jobs |
| Explicit recipient and asset | Sending value to an unintended destination |
| Input hash and requester binding | Redeeming a price for different work or caller |
Together, these fields reject mutated terms, expired quotes, replayed digests, and wrong inputs. They do not replace limits on job execution, input size, concurrency, or wallet spend.
What usually goes wrong
The rate is current but the amount is wrong. Check the token’s decimals and whether the displayed amount is whole tokens or smallest units.
The amount is correct but settlement fails. Check the CAIP-2 network, asset contract, transfer method, EIP-3009 domain, and facilitator support as one configuration.
The quote is signed but cannot be redeemed. Check expiry, maximum quote age, requester binding, input hash, chain domain, and whether the digest has already been used.
A zero or tiny amount appears for a cheap job. Check flooring, minimum price policy, and the decimal scale before calling the job free.
The operator earns less than expected. Include gas, failed work, refunds, rate drift, facilitator costs, and support in the base price or markup policy.
The buyer receives a successful payment response but no result. Payment is a settlement event, not a completion proof. Use the job identifier and runner evidence to reconcile execution separately.
Start with a static price and a refresh rule
Operators do not need an auction engine on day one. A durable progression is:
- Set one clear per-job wei price.
- Configure one accepted testnet token and verify the conversion.
- Run a complete payment and result flow on testnet.
- Record the exchange-rate source and quote TTL.
- Add a controlled refresh process when drift affects margin or buyer expectations.
- Add per-Blueprint or per-job overrides only when the cost distribution justifies them.
The public pricing engine supports service-creation and per-job RFQ modes, while Tangle’s protocol also exposes subscription and event-driven pricing models. That does not mean every service needs every path. The pricing model should mirror the cost the buyer can understand.
For the HTTP payment boundary, the x402 payment guide shows how a displayed price becomes a payment requirement and then a paid job call. For recurring access, subscription versus pay-per-request API pricing works through the buyer-side break-even decision.
What is pay-per-request API pricing?
It charges for a defined unit of work, such as one job, document, browser scenario, or inference request. The price should be tied to a result the buyer can identify and reconcile.
Why are job prices stored in wei?
Wei gives the job price a native-token denomination that can be converted into accepted tokens later. The conversion can apply a token-specific exchange rate, decimal scale, and markup without rewriting the job’s base price.
What does 200 basis points mean?
It means a 2% markup because 100 basis points equal 1%. A converted 3.200 USDC amount becomes 3.264 USDC before it is represented as 3,264,000 six-decimal smallest units.
Does an EIP-712 signature prove a job is correct?
No. It proves that the signed fields came from the signing key and were not changed before verification. Correctness needs a separate result check, evidence bundle, or evaluation.
How often should an operator update the exchange rate?
Use the service’s volatility, margin tolerance, quote TTL, and rate-source availability to set the policy. The current configuration does not remove that operating decision.
Can an operator accept multiple tokens?
The Blueprint configuration supports multiple accepted-token entries. Each entry needs its own network, asset, decimals, receiving address, exchange rate, markup, and transfer settings.