«Esta perda/benefício já foi liquidada»: na regra de contratos perpétuos, isso só pode ser uma declaração aguardando arbitragem.
Tendo como pano de fundo o modelo de pool de liquidez multiactivos da Tribe Perpetual, suponha que o destino de uma posição dependa de uma sequência de números enviada por um oráculo externo. Na camada de negócios, não se trata de como a mensagem é encaminhada, e sim se a própria arbitragem se sustenta: a declaração a que posição (head/ponta) está ancorada, se os dados de preço submetidos correspondem a ela, se o contrato on-chain consegue concluir a verificação de forma independente e que tipo de poder de atuação essa conclusão de verificação concede ao motor de liquidação. Sem um limiar de admissibilidade, qualquer nó poderia submeter cotações favoráveis; sem evidências verificáveis para auditoria, o protocolo perde a base para aceitar ou recusar.
Por isso, a oracle verification está na camada intermediária da arbitragem de negócios. Ela converte «alguém reportou assim de uma certa fonte» em «esses dados podem ser auditados», e então entrega a conclusão da auditoria à lógica de liquidação. Essa posição determina se a posição pode ser liquidada de maneira consistente e também se o mesmo pool de liquidez consegue ser expandido para mais ativos, e não uma simples justificativa de preço que tanto faz.
Quanto a pesquisas correlatas sobre transmissão de preços com baixa latência e as premissas de segurança de derivativos on-chain, elas colocam precisamente a dificuldade aqui: o artigo e a proposta de infraestrutura discutem o custo, a latência e os limites do jogo de um oracle baseado em pull, e usam o cenário de liquidação de contratos perpétuos para explicar a importância da verificação de preços para derivativos on-chain. Elas constituem apenas contexto de pesquisa; podem explicar por que a alegação de preço tem dificuldade de ser aceita, mas não podem ser descritas como se o TMX atual já tivesse integrado um esquema específico de oráculo, nem servir como prova definitiva de uma arquitetura de produto.
As práticas iniciais de perp DEX também indicam que o pool de liquidez não precisa depender do tradicional book de ordens: ainda assim é possível concluir uma liquidação verificável de posições altamente alavancadas; isso apenas complementa a orientação de que a market-making capital-efficient não precisa migrar para CEX e não participa do processo de arbitragem desta peça.
Voltando a uma observação sobre uma posição do TMX, fica apenas uma pergunta: qual informação verificável sustenta o estado de liquidação dessa posição?
#termmax @TermMax
Tendo como pano de fundo o modelo de pool de liquidez multiactivos da Tribe Perpetual, suponha que o destino de uma posição dependa de uma sequência de números enviada por um oráculo externo. Na camada de negócios, não se trata de como a mensagem é encaminhada, e sim se a própria arbitragem se sustenta: a declaração a que posição (head/ponta) está ancorada, se os dados de preço submetidos correspondem a ela, se o contrato on-chain consegue concluir a verificação de forma independente e que tipo de poder de atuação essa conclusão de verificação concede ao motor de liquidação. Sem um limiar de admissibilidade, qualquer nó poderia submeter cotações favoráveis; sem evidências verificáveis para auditoria, o protocolo perde a base para aceitar ou recusar.
Por isso, a oracle verification está na camada intermediária da arbitragem de negócios. Ela converte «alguém reportou assim de uma certa fonte» em «esses dados podem ser auditados», e então entrega a conclusão da auditoria à lógica de liquidação. Essa posição determina se a posição pode ser liquidada de maneira consistente e também se o mesmo pool de liquidez consegue ser expandido para mais ativos, e não uma simples justificativa de preço que tanto faz.
Quanto a pesquisas correlatas sobre transmissão de preços com baixa latência e as premissas de segurança de derivativos on-chain, elas colocam precisamente a dificuldade aqui: o artigo e a proposta de infraestrutura discutem o custo, a latência e os limites do jogo de um oracle baseado em pull, e usam o cenário de liquidação de contratos perpétuos para explicar a importância da verificação de preços para derivativos on-chain. Elas constituem apenas contexto de pesquisa; podem explicar por que a alegação de preço tem dificuldade de ser aceita, mas não podem ser descritas como se o TMX atual já tivesse integrado um esquema específico de oráculo, nem servir como prova definitiva de uma arquitetura de produto.
As práticas iniciais de perp DEX também indicam que o pool de liquidez não precisa depender do tradicional book de ordens: ainda assim é possível concluir uma liquidação verificável de posições altamente alavancadas; isso apenas complementa a orientação de que a market-making capital-efficient não precisa migrar para CEX e não participa do processo de arbitragem desta peça.
Voltando a uma observação sobre uma posição do TMX, fica apenas uma pergunta: qual informação verificável sustenta o estado de liquidação dessa posição?
#termmax @TermMax