Una entrada de Dusk ya finalizada puede ser real y aun así ser la cosa equivocada que no debo acreditar como depósito. Ese es el engaño del escáner que yo protegería primero. moonlightHistory(receiver) no es un feed de “depósitos de clientes”. Puede devolver transferencias directas de Moonlight, pagos de contratos, reembolsos, retiros de staking y conversiones de Phoenix a Moonlight, porque todas pueden aumentar la misma cuenta pública.

Así que no puedo reducir la ingesta a “receiver coincide y value > 0.”

Para un depósito directo de Moonlight, necesito que el propio evento de contrato de la transferencia sea el que cumpla: el topic moonlight, reverted false, el receiver esperado y un value positivo. Dusk incluso advierte en contra de adivinar la familia de la transacción contando eventos, porque una transacción puede emitir eventos de contrato adicionales sin que cambie lo que realmente es.

La consecuencia es desagradable en la contabilidad de custodia. Si mi escáner acredita cada entrada ya finalizada, un reembolso interno o un retiro de staking puede entrar en la misma ruta del libro contable que el dinero nuevo de un cliente. El saldo de la cadena es correcto mientras que mis pasivos con clientes quedan mal.

Prefiero rechazar una entrada desconocida antes que llamarla depósito en silencio.

En Dusk, finalizado me dice el dinero que se movió. El tipo de evento me dice por qué.

#dusk $DUSK @Dusk