A live check of API3's AirnodeHub on October 4 reduced a signed market-data response from 1,244 to 352 bytes by requesting only two fields. The test used the CoinGecko listing's coinsMarkets operation and retained the Ethereum identifier and current-price field instead of returning the full market record.
This is a product test, not a newly announced release. The listing identified the operation as free before either request was made. Both requests selected Ethereum, used USD and limited the result to one record. The second added a responseProjection mapping id to /0/id and price to /0/current_price.
The complete data payload measured 849 UTF-8 bytes; the projected payload measured 33. Including the Airnode address, request hash, signing timestamp and signature, the compact JSON attestation shrank by about 72%. These measurements exclude the outer MCP transport and JSON-RPC wrappers. They measure response bytes, not model tokens, billed savings or network latency.
The important difference from deleting fields after receiving a response is that the requested selection is included in the signed request. AirnodeHub's MCP documentation describes how the selected fields become the returned data and must accompany the verification request.
The Hub's verify-attestation tool accepted the projected response with the original parameters and field selection. A second verification attempt changed the price pointer to market capitalization; the tool rejected it as a different request. No independent local cryptographic verification was performed for this test.
That result illustrates request binding, not proof that a market price is correct. The listing is third-party: its signature identifies the Airnode relaying CoinGecko data, rather than a signature issued by CoinGecko itself. The attestation specification explains that distinction and the local verification procedure. A separate response-verification walkthrough provides the broader sequence.
For applications displaying a few values, smaller signed responses can reduce unnecessary data handling. The tradeoff is deliberate omission: a consumer needing the upstream update time, currency context or another field must preserve it explicitly rather than assume the price alone is sufficient.