Para desenvolvedores / Ativos do mundo real
Como um preço é formado
Dois métodos de agregação, um único publicador. A aritmética abaixo é o que torna um preço robusto ao mau comportamento de um mercado; não é ela que o torna digno de confiança. Isso é a última seção, e é a que se deve ler antes de liquidar qualquer coisa sobre esses números.
De onde vem um preço
Thirteen feeds are aggregated from five public spot venues, each subscribed with that venue's own product id. The other twenty have no venue leg and come from Pyth Network's Hermes service alone.
| Fonte | O quê |
|---|---|
| Mercados à vista | Coinbase, Kraken, Bitstamp, Gemini, Bitfinexcada um inscrito com o identificador de produto próprio daquele mercado, tirado do catálogo |
| Segunda fonte | Pyth Network, através do seu serviço Hermesa única fonte para os vinte feeds sem perna de mercado, e uma verificação cruzada para os outros treze |
Os dois métodos falham de maneiras diferentes, e um consumidor precisa dos dois comportamentos. Um feed lastreado por mercados sobrevive a um mercado que se apaga, porque a mediana é tirada sobre cinco e cada um carrega a sua própria atualidade. Um feed de fonte única não pode sobreviver à indisponibilidade da sua fonte, e diz isso em vez de adivinhar.
Quando um mercado conta
Cada mercado é avaliado sozinho antes que qualquer coisa seja combinada. As regras são aplicadas nesta ordem, e a primeira que falha tira o mercado da mediana para aquela avaliação:
| Regra | Limiar |
|---|---|
| Connection state | must be onlinea venue whose socket is down is never fresh, whatever its last quote said |
| Quote age | 10 smeasured on a MONOTONIC receive clock, never on the exchange's timestamp or the host's wall clock |
| Delivery lag | 5 s either waya timestamp trailing its receipt means the socket is replaying a backlog; one leading it means the venue dates quotes in the future. The whole venue sits out rather than falling through to its last trade |
| Spread | 50 bpsthe mid is used when the book is uncrossed and tighter than this |
| Last trade | 60 sthe fallback when no usable mid exists, inside its own longer window |
Não no timestamp da exchange, e não no relógio de parede do host. Um mercado com um relógio adiantado ou atrasado não pode fazer a sua própria cotação parecer atual, e um host cujo relógio dá um salto não pode invalidar todos os mercados de uma vez. O timestamp da exchange serve para uma coisa só: a verificação do atraso de entrega, que o compara com o momento da recepção nos dois sentidos.
O melhor bid e o melhor ask são preferidos quando o livro é recente, não cruzado e mais apertado que o limite de spread. Caso contrário a última negociação entra no lugar, dentro da sua própria janela mais longa. Um mercado cujo socket está reproduzindo um acúmulo é retirado inteiramente em vez de cair para a sua última negociação, porque essa negociação está atrasada na mesma medida.
A mediana
- Evaluate every venue against the rules above and keep the fresh ones.
- If fewer than minSources are fresh, publish nothing and report the reason - no_sources when none is fresh, too_few_sources otherwise. Nothing thin is ever published.
- Take the median of what survives.
- If the spread between the included venues exceeds 200 bps and dropping one would still leave minSources, drop the venue furthest from the median - on a tie the older observation - and take the median again. At most one venue is dropped.
- Round half-even to the feed's decimals. The result is an integer, not a float.
- Date the aggregate with the NEWEST included quote, capped at the current wall clock so no venue with a fast clock can date a median into the future.
degraded is set when the median rested on exactly minSources venues: still published, one drop-out from silence.
Um feed magro demais não publica nada em vez de publicar alguma coisa
minSources é por feed, e vale 3 em todo feed lastreado por mercados. Abaixo dele não há resposta nenhuma: nenhum último valor conhecido é republicado na cadeia, a rodada não avança e updatedAt para de se mover. O serviço ainda reporta a última boa resposta como lastKnown para fins de diagnóstico, e esse campo explicitamente não é um preço sobre o qual negociar.
O agregado é datado com a cotação incluída mais recente, limitada ao relógio de parede atual. As duas metades importam: um mercado cuja última negociação, de sessenta segundos de idade, entrou no lugar de um livro defasado não deve datar uma mediana cujas outras entradas são infra-segundo, e nenhum mercado com um relógio adiantado pode empurrar uma hora de observação para o futuro - onde o contrato a pularia como razão 4.
Verificação cruzada e substituição
An exchange-backed feed that also has a Pyth leg is cross-checked against it on every evaluation. Within 100 bps the two are recorded as agreeing; beyond it the feed is marked diverged and the dispersion flag is raised.
When the venues go stale, Pyth may stand in for them - but only if the two agreed recently and are not diverging now. A feed publishing from the stand-in is marked degraded and its source reads pyth rather than exchanges-median, so a consumer can tell. If they are diverged and Pyth is fresh, the feed publishes nothing and reports cross_check_diverged.
Dois campos expõem isso. crossCheckBps é a distância atual entre os dois métodos, e source diz qual deles produziu a rodada que você tem em mãos - 1 para a mediana dos mercados, 2 para a segunda fonte. Um feed cuja source mudou continua sendo um preço válido, produzido de outra maneira; se isso importa para o seu produto, observe o campo em vez de inferi-lo.
A segunda fonte
Toda atualização da segunda fonte passa por estas verificações antes de ser elegível a virar um preço. Uma atualização rejeitada incrementa um contador por razão, visível feed a feed nas rotas de fonte e de auditoria do serviço:
| Verificação | Limite |
|---|---|
| Exponent | pinned on the first updateany later drift is rejected, so a silent rescaling cannot pass |
| Slot and publish time | must advancean update that does not move them forward is dropped |
| Future tolerance | 5 sa publish time further ahead than this is rejected |
| Confidence | 50 bps crypto and index, 30 equity, 10 commodity and fxthe reported confidence interval as a fraction of the price; wider is rejected |
| EMA band | 10 % crypto and index, 5 % elsewherea jump away from the exponential moving average needs a SECOND sample within 100 bps of the first before it is used. A lone spike is dropped |
| Freshness | 10 s since receipt, 30 s publish lagboth measured at receipt on the monotonic clock |
Sem a credencial, vinte dos trinta e três feeds ficam em silêncio
The upstream needs a credential. Without one it answers unauthorised and every feed with no venue leg stays unpublished - twenty of the thirty-three, which is the whole real-world set plus XMR/USD.
The thirteen exchange-backed feeds continue: they are computed from public venues and need no credential. What they lose is the cross-check and the stand-in, since neither can be established without a Pyth price to compare against. Readiness reports this as a warning rather than a failure, so the service looks healthy while two thirds of the catalog is silent - check the per-feed status, not the service's.
A verificação de expoente é a discreta e a mais importante. A escala de uma atualização é fixada a partir da primeira autenticada e qualquer desvio posterior é recusado de imediato, porque um reescalonamento silencioso é um preço errado por uma potência de dez que parece perfeitamente bem formado.
Como ele chega à cadeia
- The aggregating service holds no signing key at all. It computes prices and serves them on an internal port.
- The node's publisher polls that port, authenticates the body with a shared HMAC of the exact bytes, and re-checks every item against on-chain state before signing - mirroring the contract's own skip rules so a bad item costs a counter rather than gas.
- The batch is written as ONE system transaction per EVM block, signed by the publisher key, which lives in the node's process and is used by nothing else in it.
- The service then reads its own result back off the chain and reports it, which is what the onchain field of every FeedView is.
At most 64 feeds go into one batch by default, and the contract's own maxBatch caps it again. A batch older than 2 s is not published.
A divisão do trabalho é o ponto. Tudo o que é lento ou falível - a consulta, a autenticação, a leitura do catálogo, a seleção, a codificação, a assinatura e o acréscimo ao log de escrita antecipada - acontece fora do caminho de selamento, que recebe uma transação pronta e a aplica ao custo de qualquer outra transação. E porque o publicador reverifica cada item contra o estado on-chain antes de assinar, espelhando as próprias regras de pulo do contrato, um agregador que envia algo ruim custa um contador em vez de uma rodada.
O modelo de confiança
A price is as trustworthy as the operator that produces blocks, and no more. The publisher is the block producer.
- One party operates the node, holds the publisher key and orders transactions. A price inherits exactly the assumption that already governs ordering.
- Nothing on chain arbitrates a price. There is no second publisher, no dispute window and no slashing: the contract checks that an item is well formed, positive, not from the future and not older than the feed's last observation, and then writes it.
- The owner role can add a feed, change a feed's policy, rotate the publisher and adjust the batch and tolerance parameters. Ownership transfer is two-step. Those are the only write paths that are not the publisher's.
- Splitting the key from the computation limits one failure, not the other: compromising the aggregating service lets an attacker propose prices, and every one is still re-checked and signed by the node. Compromising the node is the end of the argument.
- If you liquidate on these prices, that is the assumption you are taking, and it is the one to state to your own users.
Nada do que está acima muda isso. As regras de mercado, a mediana, a rejeição de valores discrepantes e a verificação cruzada tornam um preço robusto contra uma fonte se comportando mal, o que é uma falha real e comum. Elas não fazem nada contra a parte que assina. Leia-as como controles de qualidade, não como um consenso.
A consequência prática para um integrador: estes preços servem a um produto cujos usuários são informados de quem os produz, e eles carregam a mesma hipótese que a ordenação das suas próprias transações - então, se você já aceita essa hipótese para usar a cadeia de todo modo, consumir os feeds não acrescenta nenhuma nova. Se o seu projeto precisa de um preço que nenhuma parte sozinha possa forjar, esta camada não o fornece e nenhum parâmetro faz com que ela o forneça.