Anatomía del exploit al locker de DxSale: captura de propiedad, un drenaje self-call y un rastro de lavado en dos cadenas

El 27 de mayo de 2026, una dirección atacante comenzó a drenar un liquidity locker de DxSale en BNB Smart Chain aproximadamente una hora y cuarenta minutos después de ser fondeada — la jugada inicial de una campaña de drenaje batch que se prolongó por varios días — y luego distribuyó fondos por dos cadenas: una pata directa y expuesta a KYC, la otra enrutada por un bridge, swaps en DEX y un mixer. Esta es la reconstrucción on-chain completa, con cada afirmación respaldada por evidencia sellada y reproducible.

Cómo leer este reporte. Cada hallazgo lleva un nivel de confianza explícito bajo mi estándar forense (OCS-FIS-V1):

• Confianza: Alta (evidencia) — directamente observable on-chain y sellado bajo cadena de custodia desde al menos dos fuentes independientes.
• Confianza: Media (hipótesis) — una interpretación razonada que la evidencia sellada sostiene pero no prueba. Se enuncia como hipótesis, nunca como hecho.

Cada hash de transacción, dirección y bloque es reproducible por cualquier tercero contra las cadenas públicas. Nombro las etiquetas de entidad que muestran los exploradores de bloques (p. ej. “DxSale Exploiter 1”, “Binance 51”) como observaciones atribuidas, no como identidades del mundo real probadas. No se nombra ni se atribuye a ninguna persona natural en este reporte.

Actualizado 2026-07-15 — registro de correcciones. Este reporte fue corregido y ampliado materialmente tras sellar nueva evidencia bajo custodia. Qué cambió: (1) la captura de propiedad (F-01) estaba subcontada — se capturaron al menos seis lockers, no tres, en una ventana de ~9 minutos; (2) la atribución de exchange del fondeador (F-02) ganó una segunda fuente sellada (Arkham Intelligence etiqueta al fondeador Bybit: Hot Wallet); (3) el drenaje (F-04) queda documentado como una campaña batch sellada — al menos 19 transacciones, 3,576 transferencias LP, 17 pools distintos; (4) el conjunto de salidas de los distribuidores (F-05) quedó probado como completo vía nonces de cuenta impuestos por consenso — el lenguaje de piso se elevó a totales exactos; (5) un hallazgo nuevo (F-11) registra que, de los lockers capturados, solo el Legacy tiene un drenaje sellado. Se añadieron anexos de transacciones completos con enlaces a exploradores en F-01, F-04, F-05, F-07 y F-08, y el pin del hash del archivo de hallazgos en el front matter de esta página se actualizó en consecuencia.

Actualizado 2026-07-19 — revisión editorial. La prosa de este reporte se revisó del plural corporativo a la primera persona del singular: OnChainSurfer es un investigador forense independiente y firma en consecuencia. Se añadió un summary de una línea al front matter para las tarjetas de listado y la meta description. Ningún hallazgo, cifra, nivel de confianza ni artefacto sellado cambió; el pin del hash del archivo de hallazgos permanece intacto.

Resumen ejecutivo

Una salvedad gobierna toda la mitad de lavado de este reporte y lo pongo por delante: la dirección atacante es un operador serial, y los fondos que movió son proceeds mezclados (commingled) de su actividad más amplia. Mi evidencia sellada no establece que los BNB y SOL específicos lavados aquí provengan del drenaje del locker de DxSale. Lo que ata el lavado al exploit de DxSale es la dirección atacante compartida, no una traza de valor sellada desde la liquidez drenada. No afirmo ninguna cifra en dólares específica de DxSale para los fondos lavados.

1. Captura de propiedad Alta · evidencia

El 2026-05-26, dentro de una ventana de ~9 minutos que abarca los bloques 100449023–100450184 (01:08:21Z a 01:17:04Z), la dirección deployer 0x47BAcf935066b802EAA0067eC14AB035B24eB78b envió al menos seis transacciones BSC exitosas, cada una invocando transferOwnership (selector 0xf2fde38b, valor 0 BNB) contra un contrato locker distinto:

• 0x2D045410f002A95EFcEE67759A92518fA3FcE677 — sin etiqueta en el explorador
• 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 — etiquetado DxSale Network: Legacy Liquidity Locker
• 0x81E0eF68e103Ee65002d3Cf766240eD1c070334d — etiquetado KIPS: Locked Wallet
• 0x5b5e94485c9628793B01A38762921Dc37B6829b6 — contrato verificado, sin etiqueta de address-book
• 0x8655E5c4D701186D16765d1CDcef6D5287E4679a — contrato verificado, sin etiqueta de address-book
• 0xf8AD74e9E5D6b12EFe27dE09Bc57d38a8E52D791 — contrato verificado, sin etiqueta de address-book

En las seis, el argumento newOwner fue 0xC4574DDEF299e7E563971e200433e592EeaaFA69 — la dirección que los exploradores etiquetan DxSale Exploiter 1. Cada transacción tuvo éxito y emitió un evento OwnershipTransferred desde el propio locker objetivo. El control de todos los lockers listados pasó a esa sola dirección en un solo lote. Seis es un piso, no un conteo exhaustivo — el conjunto está muestreado del historial de transacciones del deployer.

Corrección (2026-07-15): una versión anterior de este reporte declaraba tres transferencias en una ventana que terminaba en el bloque 100449822. Ambas cifras eran subconteos; se sellaron tres capturas adicionales y la ventana se extiende hasta el bloque 100450184.

Anexo de transacciones (F-01):

Lo que no afirmo: los datos on-chain por sí solos no distinguen un insider malicioso de una llave deployer comprometida, y una migración interna benigna es lógicamente posible — pero queda debilitada por el drenaje posterior del Legacy Locker y por la ausencia de cualquier anuncio oficial de migración de DxSale.

2. Fondeo previo al ataque Alta · evidencia

En la transacción 0xffc7b601d90f6bc5584a9880693eb41f41ad62619e863e97b5d72477f5e4b72a (bloque 100798786, 2026-05-27T20:57:54Z, éxito), la dirección 0x318d2aAe4C99c2e74F7B5949fa1C34DF837789B8 envió exactamente 104.1473 BNB a la dirección atacante como transferencia simple (call data 0x, sin método). La página sellada de la transacción en BscScan muestra al emisor etiquetado Bybit 17 y al receptor DxSale Exploiter 1 (la captura RPC cruda, sellada junto a ella, no lleva etiquetas de entidad).

Este fondeo entrante precede al drenaje por 1h 39m 51s (respecto al timestamp del drenaje, sellado por separado en F-03).

Límites honestos:

• La atribución al exchange descansa en dos etiquetadores de terceros independientes, ambos sellados: el tag Bybit 17 de BscScan y la página de entidad del emisor en Arkham Intelligence, que lo etiqueta explícitamente Bybit: Hot Wallet (junto a Bybit Proof of Reserves y Centralized Exchange) y muestra la misma salida de 104.147 BNB hacia el atacante el 2026-05-27. La caracterización de “hot wallet” la afirma la etiqueta de Arkham — ya no es inferencia mía. No audité de primera mano el proceso de ninguno de los dos etiquetadores; los hechos de la transferencia (monto, direcciones, bloque, éxito) son de confianza Alta con independencia de las etiquetas.
• Una transferencia simple desde una wallet etiquetada de exchange es consistente con un retiro ordinario de cliente. No establece, por sí sola, que el exchange haya dirigido fondos hacia el drenaje, ni prueba intención.

3. El drenaje, tal como se observa on-chain Alta · evidencia

En el bloque 100812090 (2026-05-27T22:37:45Z), la transacción 0xb107f19af1a8ff90d19cbb40d935f8be5d79f5fb9b497824e4ed28b9e7555fe9 se ejecutó con estado éxito como un self-call — from y to son ambos la dirección atacante 0xC4574DDEF299e7E563971e200433e592EeaaFA69. Llevó 0 BNB e invocó el selector personalizado y no verificado 0x11b432b4.

Rederivé el efecto de primera mano desde el getTransactionReceipt sellado (RPC público), no solo desde el decode del explorador. El receipt lleva 10 event logs crudos:

• 5 son eventos Transfer ERC-20/BEP-20 del token LP de PancakeSwap (Cake-LP) 0x88DA6Bc38D5BFEF6e332F87E06a310a9e5f768E2, cada uno moviendo 12.872812929106341247 unidades (suma 64.364064645531706235) desde el Legacy Liquidity Locker 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 hacia la dirección atacante.
• Los otros 5 son eventos no-Transfer emitidos por el contrato locker, que deliberadamente no caracterizo más.

La transacción se muestra con una Dirección Delegada EIP-7702 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310.

Nota de alcance: el “5” es el conteo de eventos Transfer, no el conteo total de logs (10). Este hallazgo registra solo hechos observables. Si algún control fue evadido, y por qué mecanismo, queda fuera de alcance aquí — ver F-04.

4. Mecanismo del drenaje Media · hipótesis

Lo que es hecho sellado — la campaña batch. El drenaje no fue una sola transacción. Al menos 19 transacciones selladas — cada una un self-call (from y to ambos el atacante) invocando el mismo selector personalizado 0x11b432b4 con 0 BNB — movieron tokens LP Cake-LP desde el Legacy locker hacia el atacante a lo largo de los bloques 100812090 → 101536778, en al menos 3,576 eventos Transfer que cubren al menos 17 contratos de pool-token distintos (todo rederivado de primera mano desde cada getTransactionReceipt sellado). Estas cifras son pisos sobre la muestra sellada: la enumeración read-only mostró una campaña materialmente mayor entre el 27 y el 31 de mayo, que afirmo solo como observación read-only, no como conteo sellado.

Anexo de transacciones (F-04):

Lo que sigue siendo hipótesis — el mecanismo. La lectura propuesta: el drenaje abusó de funciones privilegiadas del locker que quedaron alcanzables después de la captura de propiedad de F-01 (una atribución OSINT consistente con write-ups públicos). Los hechos sellados sostienen esta lectura pero no la prueban.

La ruta exacta de evasión permanece abierta porque:

• El selector 0x11b432b4 es personalizado y no verificado — no he descompilado ni resuelto por ABI el código llamado, así que no puedo confirmar que sea un retiro del locker solo-para-owner en vez de un patrón genérico de multicall/router/agregación.
• El contrato auxiliar en el delegado EIP-7702 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310 tiene bytecode sin leer — la delegación podría implementar la lógica de transferencia ella misma, con lo que la función propia del locker podría no ser el vector.
• La captura de propiedad como precondición habilitante es inferida y correlacionada por tiempo, no probada causalmente dentro de esta transacción.

Resolver el mecanismo exige deconstruir el locker y los contratos auxiliares — diferido.

5. Distribución a través de BSC Alta · evidencia

Entre los bloques BSC 100869981 y 100977493 (cada transacción sellada individualmente como JSON getTransactionByHash):

• Fondeo de los distribuidores: la dirección atacante envió 1,542.285 BNB al distribuidor DIST-01 0xb71c1C2A0cD7A88f1317f9A996e4d121E7db5E92 (4 tx) y 1,438.285 BNB al distribuidor DIST-02 0x4c5ee9703653C8e7725C65593bff372655e0453C (4 tx).
• Distribución: 22 salidas selladas de DIST-01 hacia 22 wallets distintas suman 1,527.28 BNB; 8 salidas selladas de DIST-02 hacia 8 wallets distintas suman 1,438 BNB — en agregado 2,965.28 BNB hacia exactamente 30 wallets receptoras distintas.
• Retornos tempranos: antes de distribuir nada, las primeras tres transacciones de DIST-01 (nonces 0–2, bloques 100873674–100913254) devolvieron 15.001 BNB al atacante — un patrón consistente con transferencias de prueba de ruta, aunque la intención no se afirma.

El conjunto de salidas está completo — probado por nonce de cuenta. Ambos distribuidores son EOAs (sus respuestas selladas de eth_getProof reportan el hash de código vacío). El nonce de una cuenta es el conteo exacto, impuesto por consenso, de transacciones que ha enviado en toda su historia, y marca 25 para DIST-01 y 8 para DIST-02 — atestado por dos proveedores independientes — igualando exactamente los conjuntos sellados, que ocupan los rangos de nonce contiguos 0–24 y 0–7 sin huecos. Cada slot de nonce que estas direcciones consumieron alguna vez mapea a una transferencia simple sellada (ninguna es una autorización EIP-7702, que también consumiría un slot). Las 30 wallets receptoras más el atacante son, por lo tanto, las únicas direcciones que alguna vez recibieron valor de estos distribuidores, al bloque 110205789. Los balances finales sellados (0.00397732929 y 0.2849957925 BNB) corroboran distribuidores casi vacíos. Lo que esto no cubre: la completitud de entradas no se afirma (entradas no selladas a nivel de polvo existen probadamente y son inmateriales), y la atribución de exchange de las 30 wallets se trata por separado (F-06) — aunque Arkham Intelligence etiqueta independientemente a los receptores de los distribuidores como Binance Deposit y reporta un Exchange Usage de 100% Binance para ambos distribuidores ($935.59K DIST-01 / $910K DIST-02, páginas selladas), como corroboración de terceros.

Anexo de transacciones (F-05):

Fondeo (atacante → distribuidores, 8 tx):

Retornos tempranos de DIST-01 al atacante (nonces 0–2, 3 tx):

Salidas de distribución de DIST-01 (nonces 3–24, 22 tx):

Salidas de distribución de DIST-02 (nonces 0–7, 8 tx):

6. Consolidación hacia una sola wallet de exchange Alta · evidencia

Muestreé 5 de las 30 wallets receptoras y sellé sus hops posteriores. Las cinco reenviaron los BNB que recibieron a la misma dirección 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3, que las páginas selladas del explorador etiquetan Binance 51:

Cada hop está sellado con dos fuentes independientes — el JSON getTransactionByHash del RPC público y la captura de la página de la transacción del explorador. La cadencia de barrido es rápida y uniforme: entre el depósito de cada wallet y su hop de salida, de 210 a 1,506 bloques (aproximadamente 95 segundos a ~11 minutos). Ejemplo trabajado, todo desde la propia página sellada de 0xAc69F86C…: depósito en el bloque 100928690 (13:13:41 UTC), hop en el bloque 100929535 (13:20:02 UTC) — 845 bloques en 381 segundos (~0.45 s/bloque), consistente con barrido automatizado. Al menos una wallet muestreada muestra FUNDED BY: Binance: Deposit Funder y ciclos repetidos de depósito-y-barrido antes y después de la ventana del exploit.

Lo que no afirmo: afirmo consolidación on-chain solo para las 5 wallets muestreadas. La afirmación “las 30 wallets consolidan en Binance” deliberadamente no se hace como afirmación on-chain — los hops de las 25 wallets restantes no fueron sellados. De forma independiente, Arkham etiqueta a los receptores de los distribuidores como Binance Deposit y reporta el Exchange Usage de ambos distribuidores como 100% Binance (páginas selladas) — corroboración de terceros que extiende la atribución del destino Binance al conjunto completo, aunque solo la muestra de 5 wallets lleva evidencia de hop sellada on-chain. Binance 51 es una etiqueta del explorador, no una identidad probada on-chain.

7. Cruce hacia Solana vía Relay.link Alta · evidencia

24 transacciones BSC exitosas movieron valor desde tres wallets relay hacia el bridge Relay.link. Cada cruce está atestado de extremo a extremo por tres artefactos sellados: (a) la transacción de origen BSC, (b) el propio registro de estado público del operador del bridge que mapea ese hash de origen exacto a una firma de fill en Solana + destino + valuación en USD, y (c) la transacción de fill de Solana misma, sellada de forma independiente.

Las tres cuentas de destino son distintas entre sí — los fondos con bridge no convergieron en una sola cuenta Solana. Del lado BSC, las entradas de RELAY-02 sumaron 8,809.826078 BUSD + 9,885.496711 USDT + 90.840809 WBNB (receipts sellados).

Anexo de transacciones (F-07) — cada cruce con sus tres artefactos sellados:

Límites honestos: los registros de estado del operador son una segunda fuente independiente pero no consenso de cadena; esto se mitiga con (c), cada fill recuperado independientemente desde un RPC público de Solana. Las cifras en USD son las valuaciones del operador al momento de la solicitud — citadas como atribuidas, no como precios propios míos. Por mi estándar de confianza, el vínculo cross-chain parte de un techo de confianza fijado de antemano — antes de mirar los datos — porque ningún hash de transacción se comparte a través de un bridge; aquí las dos fuentes independientes coinciden en identificadores exactos de transacción, lo que lo eleva a Alta.

8. Swaps y la frontera del mixer Alta · evidencia

Aguas abajo en Solana (todas las cantidades son deltas de balance de JSONs getTransaction sellados; el RPC de Solana sí enumera las firmas de una cuenta, así que los deltas por transacción son de confianza Alta, pero la completitud del conjunto descansa en esa enumeración — los conteos son pisos):

• Traspasos: 2dQg9J… reenvió 1,020.653 SOL a AgnEKmN1XHBduneu9bFu1bfp69GRVUuCyNpQjAHSJ6do (2 tx); 8E6SHPRJ… reenvió 4,631.92 SOL a 3vy9hoGMq382E48EEyGuEYTeP8Raya8WRVRgbrvCGxKY (2 tx). (Las formas abreviadas de estas dos cuentas se usan más abajo tras esta primera mención completa.)
• Swaps en DEX a USDT (2026-06-02): A6uMgTcF… convirtió 5,300.156953 SOL → 400,000 USDT (su salida de swap iguala su posterior única salida de 400,000 USDT — el balance cierra); 3vy9hoGM… convirtió 2,324.482379 SOL → 173,500.88 USDT; AgnEKmN1… convirtió 513.30551 SOL → 38,305 USDT.
• Un camino termina en un depósito de exchange expuesto a KYC: AgnEKmN1… envió 38,276 USDT a B3KoJ9TETMmEiAUPMXzeCJsTvHh2rn1mawj3NZMi1zrf (2026-06-08), una cuenta cuya página sellada de Solscan muestra las etiquetas literales #Binance Exchange y #Deposit Address — el único endpoint expuesto a KYC observado del lado Solana, y el hilo que ata esta pata de vuelta a un exchange alcanzable por orden judicial (≈$38K de un tramo con bridge valuado por el operador en ≈$1.35M; el camino mayoritario termina en el mixer y el fan-out no enumerado). Por separado, el pool 4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGh — nombre público en Solscan Privacy Cash Pool, owner Privacy Cash — fue acreditado con 1,107.4496944 SOL en 6 depósitos sellados (183.5 SOL desde AgnEKmN1…; 923.9496944 SOL desde 3vy9hoGM…).

Anexo de transacciones (F-08) — las 35 transacciones Solana selladas detrás de esta sección:

La parada honesta: salidas materiales (400,000 USDT + 5,424.15 SOL desde el destino de RELAY-01, y salidas adicionales desde 3vy9hoGM…) fueron a cuentas que no enumeré. El mixer es una frontera dura de visibilidad — los depósitos son observables, los retiros son no vinculables on-chain. Por eso no afirmo ninguna atribución terminal de la pata Solana ni ninguna afirmación sobre dónde aterrizó la mayoría de su valor.

9. Un aparato EIP-7702 Alta · evidencia

La dirección atacante operó bajo delegación EIP-7702 (transacción tipo 0x4) en BSC. Sellado on-chain: la transacción 0x6f83d59da4de3ac68c9cb941530daa2d75d33c6e43497ee0dc6a8efbc171e211 (bloque 101536427) delega la autoridad de la cuenta del atacante a 0x44BCb3eAeE1C15f5D669A2B5e628d42c1ec19A18 en chainId 0x38. Las páginas selladas del explorador muestran: más de 10,000,000 de autorizaciones EIP-7702, valores de nonce de autoridad de hasta 123,429 al 2026-05-31, y — en la página del contrato delegado — CONTRACT CREATOR: DxSale Exploiter 1, la propia etiqueta del atacante.

Contraste, sellado on-chain: las wallets relay RELAY-01 y RELAY-02 también ejecutaron transacciones tipo 0x4, pero delegan a 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B — un delegado de wallet estándar ampliamente desplegado — no al delegado personalizado del atacante.

Alcance: las cifras de escala (>10M autorizaciones, nonce 123,429) son agregados computados por el explorador sobre capturas selladas, no rederivados por mí; el bytecode del delegado no fue deconstruido. Esto es una semilla para una investigación dedicada.

10. Dos posturas de opsec — sobre fondos mezclados Media · hipótesis

Esto es un marco interpretativo sobre los hallazgos de evidencia anteriores; no afirma hechos nuevos, ni identidad, ni intención. Y hereda la salvedad de commingling por completo: la dirección atacante es un operador serial (123,448 transacciones; el aparato EIP-7702 de F-09), y los fondos de abajo son sus proceeds mezclados. La evidencia sellada no establece que provengan del drenaje del locker de DxSale específicamente. El vínculo con DxSale es la dirección compartida, no una traza de valor.

Dicho eso, las dos cadenas lucen muy distintas:

• BSC — ofuscación mínima. Atacante → 2 distribuidores → exactamente 30 wallets (2,965.28 BNB, salidas completas por nonce), con las 5 wallets muestreadas barriendo a una sola hot wallet Binance 51: una salida directa y expuesta a KYC que concentra cualquier apalancamiento de orden judicial en un exchange.
• Solana — bastante más sofisticación. El tramo con bridge (valuado por el operador en ~$1,350,897.92 a través de 24 cruces) se dividió en tres destinos, se swapeó a USDT, se envió 1,107.45 SOL a un mixer Privacy Cash y se abrió hacia cuentas no enumeradas — con solo 38,276 USDT llegando a una cuenta de depósito etiquetada de Binance.

Lecturas posibles, ninguna afirmada: (a) operadores o playbooks distintos por cadena; (b) un operador aplicando mayor opsec al tramo cross-chain; (c) la salida BSC se apoyó en cuentas mula o comprometidas donde la exposición KYC era aceptable. La asimetría también podría ser un artefacto de qué tan profundo enumeré cada lado. Lo enmarco para el lector; no lo resuelvo.

11. Capturados, pero no drenados Media · hipótesis

De los al menos seis lockers capturados (F-01), solo el Legacy Liquidity Locker 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 tiene un drenaje sellado on-chain hacia el atacante (F-03/F-04). Para los otros cinco, los chequeos read-only (filtros de transferencias del explorador de cada locker hacia el atacante) devolvieron ninguna transacción de drenaje al momento de esos chequeos.

Esta es una observación NEGATIVA acotada y de fuente única — una ausencia de drenaje observado en chequeos read-only, no una prueba de que esos lockers nunca fueron drenados o no puedan serlo; la confirmación exhaustiva exigiría scans de rango con nodo archive, fuera del tooling read-only de esta investigación. Bajo esta observación acotada, cinco lockers capturados permanecieron bajo propiedad del atacante sin drenaje observado, dejando su liquidez bloqueada expuesta al mismo vector de captura de propiedad ejercido contra el Legacy locker. El reporte independiente de terceros (rekt.news) caracterizó una exposición residual comparable como “$15.5M still at risk” — cito esa cifra solo como reporte externo, no como cantidad sellada, y no valúo independientemente la liquidez expuesta.

Lo que esta investigación no afirma

• Ninguna cifra en dólares específica de DxSale para los fondos lavados. Los fondos son proceeds mezclados de un operador serial; el vínculo con DxSale es la dirección compartida, no una traza de valor sellada.
• Ninguna identidad del mundo real. Toda referencia a “Binance”, “Bybit”, “DxSale Exploiter” y “Privacy Cash” es una etiqueta de entidad del explorador de bloques — una observación atribuida, no una identidad probada, y nunca una persona natural.
• Ningún conteo exhaustivo en BSC — con una excepción probada. Los conteos de wallets y transacciones del lado EVM son pisos, excepto el conjunto de salidas de los distribuidores (F-05), probado completo vía nonces de cuenta impuestos por consenso. La atribución de exchange de las 30 wallets receptoras descansa en la muestra sellada de 5 wallets más la corroboración de terceros (Arkham) — no en hops sellados para las 30.
• Ningún aterrizaje terminal en Solana. El mixer y el fan-out no enumerado son fronteras duras.
• Ningún mecanismo de drenaje probado. F-04 es una hipótesis pendiente de deconstrucción de contratos.

Metodología y custodia

Cada transacción, dirección y bloque citado es reproducible por cualquier tercero contra las cadenas públicas BNB Smart Chain y Solana. Toda la evidencia está sellada bajo una cadena de custodia de escritura única (WORM): cada artefacto es hasheado por contenido (SHA-256) al capturarse y los hashes quedan fijados (pin); el conjunto de hallazgos se valida con un gate mecánico de exportación antes de publicar. Los niveles de confianza siguen mi estándar forense OCS-FIS-V1: el lenguaje afirmativo se usa solo para evidencia sellada y observable, y las interpretaciones se etiquetan como hipótesis. El rastro público preexistente de este caso se trató solo como pista — cada hecho aquí fue rerecolectado y resellado de forma independiente.

Las direcciones y hashes de transacción de referencia aparecen en línea arriba y resuelven directamente en los exploradores públicos.