Um evento de Dusk arquivado pode descrever uma mudança de estado que nunca aconteceu
Um backend pode ler um evento do arquivo finalizado do Dusk e ainda assim tomar a decisão financeira errada.
Desde que Boreas ficou ativo na mainnet no bloco de reinício 4.414.095, o Dusk deliberadamente retém eventos de contratos revertidos nos dados do arquivo com um marcador de revertido. Esses eventos são evidência histórica de que a execução os produziu — não prova de que os efeitos de seu estado sobreviveram.
Após o Boreas, eventos revertidos são excluídos do block bloom canônico, e eventos de stake revertidos não atualizam o estado do provisioner.
Essa distinção importa onde quer que eventos se tornem mutações no banco de dados. Um indexador que trata “o evento existe” como “a operação foi bem-sucedida” pode creditar um depósito, registrar um pagamento ou acionar a lógica downstream para um estado que a chain reverteu.
A própria orientação de depósitos do Moonlight do Dusk deixa a regra explícita: um depósito direto é aceito apenas quando o evento de transferência corresponde à operação esperada e event.reverted === false.
Portanto, a finalização responde uma pergunta: o histórico arquivado está resolvido? Ela não apaga a necessidade de interpretar o que esse histórico diz.
Para integrações do Dusk após o Boreas, revertido não é metadado para ignorar. Ele faz parte da condição de aceitação que separa evidências de execução histórica do estado canônico.
@Dusk $DUSK #dusk
Um backend pode ler um evento do arquivo finalizado do Dusk e ainda assim tomar a decisão financeira errada.
Desde que Boreas ficou ativo na mainnet no bloco de reinício 4.414.095, o Dusk deliberadamente retém eventos de contratos revertidos nos dados do arquivo com um marcador de revertido. Esses eventos são evidência histórica de que a execução os produziu — não prova de que os efeitos de seu estado sobreviveram.
Após o Boreas, eventos revertidos são excluídos do block bloom canônico, e eventos de stake revertidos não atualizam o estado do provisioner.
Essa distinção importa onde quer que eventos se tornem mutações no banco de dados. Um indexador que trata “o evento existe” como “a operação foi bem-sucedida” pode creditar um depósito, registrar um pagamento ou acionar a lógica downstream para um estado que a chain reverteu.
A própria orientação de depósitos do Moonlight do Dusk deixa a regra explícita: um depósito direto é aceito apenas quando o evento de transferência corresponde à operação esperada e event.reverted === false.
Portanto, a finalização responde uma pergunta: o histórico arquivado está resolvido? Ela não apaga a necessidade de interpretar o que esse histórico diz.
Para integrações do Dusk após o Boreas, revertido não é metadado para ignorar. Ele faz parte da condição de aceitação que separa evidências de execução histórica do estado canônico.
@Dusk $DUSK #dusk
