Emphasize first-party oracle model throughout the book

Airnode is designed for API providers to operate their own nodes.
The docs now consistently reinforce this, clarify the trust gap
with third-party operators, and guide consumers to verify operator
identity via DNS before trusting an airnode.

Author: andreogle

book/docs/concepts/endpoint-ids.md

@@ -92,12 +92,17 @@ These fields do not affect the endpoint ID:
 
 ### Cross-operator comparability
 
-When two independent operators serve the same API endpoint with the same parameters and encoding, they produce the same
-endpoint ID. On-chain contracts can verify that data from different airnodes refers to the same underlying data point
-without trusting a centralized registry.
+When two independent first-party operators serve the same API endpoint with the same parameters and encoding, they
+produce the same endpoint ID. On-chain contracts can verify that data from different airnodes refers to the same
+underlying data point without trusting a centralized registry.
 
-This is how beacon aggregation works: multiple airnodes produce beacons for the same endpoint ID, and a data feed
-contract aggregates them into a single value. The endpoint ID is the common key.
+This is how beacon aggregation works: multiple first-party airnodes produce beacons for the same endpoint ID, and a data
+feed contract aggregates them into a single value. The endpoint ID is the common key.
+
+Note that a matching endpoint ID proves two operators committed to the same API specification — it does not prove they
+are actually calling it. With first-party airnodes (where the API provider operates the node), this is inherently
+trustworthy. With third-party operators, a matching endpoint ID provides weaker guarantees because the operator could
+fabricate data while claiming to serve the specified API.
 
 ### TLS proof verification
 

book/docs/consumers/getting-started.md

@@ -23,12 +23,19 @@ curl http://airnode.example.com/health
 
 Save the `airnode` address. You need it to verify signatures.
 
-## Step 2: Find your endpoint ID
+## Step 2: Verify the operator
+
+Before trusting an airnode, verify that it is operated by the API provider — not a third party. Use
+[DNS identity verification](/docs/security/identity-verification) (ERC-7529) to confirm the airnode address is
+associated with the API provider's domain. A first-party airnode (operated by the data source) provides the strongest
+trust guarantees. See the [Trust Model](/docs/security/trust-model) for why this matters.
+
+## Step 3: Find your endpoint ID
 
 The airnode operator provides the endpoint ID for each API route. It is a `bytes32` hash derived from the endpoint's OIS
 specification. The operator's documentation lists available endpoint IDs and their expected parameters.
 
-## Step 3: Make a request
+## Step 4: Make a request
 
 Call the endpoint with parameters in the JSON body.
 
@@ -63,7 +70,7 @@ If the endpoint has no encoding configured, you get `rawData` instead of `data`:
 }
 ```
 
-## Step 4: Verify the signature
+## Step 5: Verify the signature
 
 Recover the signer address and compare it to the airnode address from `/health`.
 
@@ -99,7 +106,7 @@ const rawDataHash = keccak(toBytes(JSON.stringify(rawData)));
 // Use rawDataHash in place of `data` in the encodePacked call above
 ```
 
-## Step 5: Decode the data
+## Step 6: Decode the data
 
 Encoded responses contain ABI-encoded values. Decode them with viem.
 
@@ -120,7 +127,7 @@ Raw responses need no decoding. Access the JSON directly:
 const ethPrice = rawData.ethereum.usd; // 3842.17
 ```
 
-## Step 6: Submit on-chain (optional)
+## Step 7: Submit on-chain (optional)
 
 Pass the signed data to an on-chain verifier contract. See [On-Chain Integration](/docs/consumers/on-chain) for contract
 examples using AirnodeVerifier (pull) and AirnodeDataFeed (push).

book/docs/guides/system-overview.md

@@ -85,20 +85,27 @@ No cache server or external infrastructure required. The airnode is the entire b
 
 ## Multi-operator setup
 
-Multiple independent airnodes serve the same API data. A cache server aggregates their signed responses. Relayers read
-from the cache server and submit on-chain with quorum verification.
+Multiple independent first-party airnodes — each operated by a different API provider — serve comparable data. A cache
+server aggregates their signed responses. Relayers read from the cache server and submit on-chain with quorum
+verification.
 
 ```
-Airnode A ──┐
-Airnode B ──┼──▶ Cache Server ──▶ Relayer ──▶ On-chain Contract
-Airnode C ──┘
+Airnode A (Provider X) ──┐
+Airnode B (Provider Y) ──┼──▶ Cache Server ──▶ Relayer ──▶ On-chain Contract
+Airnode C (Provider Z) ──┘
 ```
 
 Use this when:
 
-- You need redundancy across independent operators.
-- On-chain consumers require data signed by multiple sources (beacon sets / quorum).
+- You need redundancy across independent API providers.
+- On-chain consumers require data signed by multiple first-party sources (beacon sets / quorum).
 - You want to decouple airnode operators from gas payment and on-chain submission.
 
 Each airnode produces its own beacon ID for the same endpoint. The cache server collects all of them. A relayer can
 aggregate them into a beacon set on-chain using median aggregation.
+
+The trust value of a multi-operator setup comes from **independence at the source level**. Multiple first-party airnodes
+from different API providers (e.g., CoinGecko, CoinMarketCap, CryptoCompare each running their own airnode) provide
+genuine redundancy — an attacker would need to compromise multiple independent data sources. Multiple third-party
+operators calling the same API do not provide this property, since they all depend on the same upstream source and
+introduce the same intermediary trust assumptions.

book/docs/introduction.md

@@ -32,7 +32,8 @@ If you're building a smart contract, dApp, or AI agent that needs real-world dat
 cryptographic guarantees.
 
 - **First-party data.** The API provider runs the Airnode and signs the data directly. No intermediary chain of oracles
-  repackaging data — the signature traces back to the source. You can verify the provider's identity via DNS (ERC-7529).
+  repackaging data — the signature traces back to the source. Verify that the airnode is operated by the API provider
+  using [DNS identity verification](/docs/security/identity-verification) (ERC-7529) before trusting its data.
 - **Verifiable off-chain and on-chain.** Every response includes an EIP-191 signature. Verify it locally in your
   application or submit it to an on-chain verifier contract. The same signature works in both contexts.
 - **Standard HTTP interface.** No proprietary SDKs or oracle-specific protocols. Send a `POST` request, get signed JSON
@@ -41,8 +42,9 @@ cryptographic guarantees.
   choose the encoding at request time with `_type`, `_path`, and `_times` parameters.
 - **Multiple access models.** Free endpoints for public data, API keys for authenticated access, NFT-gated endpoints for
   token holders, or pay-per-request via x402. Use whatever fits your use case.
-- **Aggregation and quorum.** Multiple independent airnodes serving the same API produce the same endpoint ID. Collect
-  signatures from several providers and submit them to a quorum verifier — no single provider can fabricate data.
+- **Aggregation and quorum.** Multiple first-party airnodes from different API providers serving comparable data produce
+  the same endpoint ID. Collect signatures from several providers and submit them to a quorum verifier — no single
+  provider can fabricate data.
 
 ## Core Flow
 

book/docs/operators/index.md

@@ -8,6 +8,16 @@ sidebar_label: Getting Started
 
 Set up and run an Airnode in under 5 minutes.
 
+## Who should run an Airnode
+
+Airnode is designed for **API providers** to serve their own data on-chain. You should be the API provider or an
+authorized representative of the API provider. This is what makes Airnode a first-party oracle — the entity that
+controls the data source also controls the signing key.
+
+If you are not the API provider, the trust properties change fundamentally. Consumers cannot verify that you are
+honestly relaying data from the upstream API, and DNS identity verification will only prove your domain — not the API
+provider's. See the [Trust Model](/docs/security/trust-model) for details.
+
 ## 1. Generate a key
 
 ```bash

book/docs/security/identity-verification.md

@@ -118,9 +118,21 @@ who sets the TXT record is claiming: "I control this domain and I operate this a
 - **It composes with existing trust**: if you already trust CoinGecko's API, verifying that their airnode address
   resolves to their domain extends that trust to their on-chain oracle.
 
+### First-party verification
+
+DNS identity verification is most meaningful for **first-party airnodes** — where the API provider operates the node.
+When CoinGecko sets a DNS TXT record associating their airnode address with `api.coingecko.com`, consumers can verify
+that the data signer is the same entity that controls the data source. This is the strongest trust configuration.
+
+A third-party operator can only verify their own domain. If `oracle-service.example.com` claims to serve CoinGecko data,
+DNS verification proves the operator controls `oracle-service.example.com` — not that CoinGecko authorized them or that
+the data is genuine. Consumers should always look for DNS verification against the **API provider's domain**, not the
+operator's domain.
+
 What identity verification does **not** prove:
 
-- That the airnode is serving correct data (the operator is still trusted to be honest).
+- That the airnode is serving correct data (with first-party operation, the provider's reputation is at stake; with
+  third-party operation, this is unverifiable).
 - That the configuration hasn't changed (the operator can update their config at any time).
 - That the DNS record is current (records can be removed, so verify close to integration time).
 

book/docs/security/trust-model.md

@@ -7,14 +7,46 @@ sidebar_position: 1
 
 Understanding what you are trusting when you consume data from an airnode.
 
+## First-party oracle model
+
+Airnode is designed around the **first-party oracle** principle: the entity that operates the API also operates the
+airnode. When CoinGecko runs an airnode serving CoinGecko's API, the signature on every response traces directly back to
+the data source. There is no intermediary oracle network, no third-party relaying the data, no trust gap between the
+signer and the source.
+
+This is important because it means the trust relationship is the same on-chain as it is off-chain. If you already trust
+CoinGecko's API for off-chain use, an airnode operated by CoinGecko extends that exact same trust on-chain. The
+signature is the API provider's signature.
+
+### Why first-party matters
+
+With a third-party oracle (someone other than the API provider running the node), consumers must trust that the operator:
+
+- Is actually calling the API they claim and not fabricating or caching responses
+- Has legitimate access to the API and is not violating terms of service
+- Is not modifying, delaying, or selectively omitting data
+- Will keep the node running and the API credentials current
+
+None of these properties can be verified on-chain today. The endpoint ID commits to *what* API should be called, but it
+does not prove the operator is actually calling it. DNS identity verification proves *who* controls a domain, but a
+third-party operator would only prove their own domain -- not the API provider's.
+
+**First-party operation eliminates this entire class of trust assumptions.** The API provider has no incentive to
+fabricate responses to their own API, already has legitimate access, and controls the infrastructure end-to-end.
+
+Consumers should prefer airnodes operated by the API provider and verify this via
+[DNS identity verification](/docs/security/identity-verification). If an airnode's identity cannot be traced to the API
+provider's domain, treat it with the same skepticism you would apply to any unverified data source.
+
 ## What you are trusting
 
 ### 1. The airnode operator is calling the API they claim
 
 The endpoint ID is a specification-bound hash that commits to the API URL, path, method, parameters, and encoding rules.
 Two independent operators serving the same API with the same config produce the same endpoint ID. This is a verifiable
 commitment -- you can inspect the config and confirm the endpoint ID matches -- but it is not proof that the operator is
-actually running that config. Until TLS proofs mature, you trust the operator to be honest.
+actually running that config. With a first-party airnode, this is not a concern: the API provider has no reason to
+misrepresent calls to their own API. Until TLS proofs mature, third-party operators require out-of-band trust.
 
 ### 2. The airnode's private key is secure
 
@@ -28,8 +60,8 @@ The first-party trust model means the API provider is already trusted. If you us
 trust CoinGecko. Airnode extends that trust on-chain -- the data is signed by the API provider's key, not by a
 third-party oracle network.
 
-For higher assurance, use a quorum of multiple independent airnodes serving the same endpoint ID. An attacker would need
-to compromise a majority to manipulate the result.
+For higher assurance, use a quorum of multiple independent first-party airnodes -- each operated by a different API
+provider serving comparable data. An attacker would need to compromise a majority of providers to manipulate the result.
 
 ## How trust is established
 
@@ -51,12 +83,18 @@ Multiple independent airnodes can serve the same endpoint ID. On-chain, you can
 sets (median of N independent values via AirnodeDataFeed). Off-chain, your client can query multiple airnodes and
 compare results. No single operator can manipulate the aggregated feed.
 
-### Future: TLS proofs
+### Future: TLS proofs and third-party trust
 
 TLS Notary (or zkTLS) can produce cryptographic proof that the data came from a specific HTTPS endpoint. This would
 eliminate the need to trust the operator's honesty -- the proof shows the data was not fabricated. When TLS proof
 technology matures, it can be integrated as a plugin or proof mode without changing the core architecture.
 
+TLS proofs are particularly significant for third-party operators. Today, a third-party operator cannot prove they are
+actually calling the API they claim. With TLS proofs, the cryptographic proof itself demonstrates the data came from
+the API provider's HTTPS endpoint -- regardless of who operates the airnode. This could make third-party operation
+viable for use cases where the API provider does not want to run infrastructure, while still preserving verifiable
+data provenance. Until then, first-party operation remains the only trust model where the data source is guaranteed.
+
 ### Future: TEE attestation
 
 Running the airnode in a Trusted Execution Environment (AWS Nitro Enclaves, Intel SGX, AMD SEV-SNP) produces attestation