Alameda transfirió más de 250 millones de dólares estadounidenses de Stablecoin a la billetera caliente de Binance

[Alameda transfirió más de 250 millones de dólares estadounidenses a Binance hot wallet Stablecoin] Noticias del 17 de junio, según datos de Bscscan, la dirección de billetera marcada por Nansen como Alameda: Binance Deposit (0x3507e4978e0eb83315d20df86ca0b976c0e40ccb) se envió a Binance en dos transacciones alrededor de las 13:00 de hoy Se transfirieron 195 545 342 BUSD y 55 070 915 USDT a la billetera, por un total de aproximadamente 250 616 257 USD.

Otras noticias:

Axelar Network: los activos de Cosmos ahora están disponibles en el ecosistema de Avalanche: el 2 de abril, Axelar Network, un protocolo de interoperabilidad entre cadenas, tuiteó que con el apoyo de Axelar, los activos de Cosmos ahora están disponibles en el ecosistema de Avalanche. El DEX Pangolin en la cadena Avalanche se ha lanzado en el grupo axlATOM-AVAX. [2022/4/3 14:01:23]

Alkimiya, un protocolo de código abierto sin licencia, lanzó hoy la red principal de Avalanche: el 26 de marzo, Alkimiya, un protocolo de código abierto sin permiso para el mercado de capitales de consenso, anunció que lanzará hoy la red principal de Avalanche. Según los informes, Alkimiya consta de dos partes: Silica es un swap de flotante a fijo emitido por productores de espacios en bloque; HashVault es una bóveda que empaqueta los contratos de Silica y reorganiza el flujo de efectivo básico en varios productos financieros.

Los vendedores en la plataforma Alkimiya pueden asegurar ingresos futuros fluctuantes en un pago inicial fijo. Esto les permite administrar mejor el riesgo en las operaciones de replanteo/minería. Los compradores reciben un flujo sostenible de ingresos directamente de la producción de espacio en bloque, que anteriormente solo estaba disponible para mineros/validadores. [2022/3/26 14:19:25]

Slow Mist: la cadena Zabu Finance en Avalanche fue pirateada: según la inteligencia del Distrito Slow Mist, el 12 de septiembre, el proyecto Zabu Finance en Avalanche sufrió un ataque de préstamo relámpago.

1. El atacante primero crea dos contratos de ataque y luego convierte WAVAX en tokens SPORE en Pangolin a través del contrato de ataque 1, e hipoteca los tokens SPORE obtenidos al contrato ZABUFarm para prepararse para las recompensas de tokens ZABU posteriores.

2. El atacante tomó prestados tokens SPORE de Pangolin Flash Loan al atacar el contrato 2 y luego comenzó a usar tokens SPORE continuamente para realizar operaciones de "hipoteca/retiro" en el contrato ZABUFarm. Dado que los tokens SPORE deben cobrar una determinada tarifa de manejo durante el proceso de transferencia (cobrada por el contrato SPORE), la cantidad real de tokens SPORE recibidos por el contrato ZABUFarm es menor que el monto de la hipoteca transferida por el atacante. En el análisis, notamos que el contrato ZABUFarm registrará directamente el monto de la hipoteca transferida por el usuario cuando el usuario hipoteca, en lugar de registrar la cantidad real de tokens recibidos por el contrato. Esto lleva al hecho de que la cantidad de tokens SPORE realmente recibidos por el contrato ZABUFarm cuando el atacante hipoteca es menor que la cantidad de tokens que el contrato ZABUFarm transfiere al atacante cuando el atacante se retira.

3. El atacante se aprovechó del defecto de contabilidad causado por el problema de compatibilidad entre el contrato ZABUFarm y los tokens SPORE, y consumió continuamente los fondos SPORE en el contrato ZABUFarm a un valor extremadamente bajo a través de operaciones de "hipoteca/retirada". La recompensa de la hipoteca del contrato ZABUFarm se calcula dividiendo las recompensas de bloque acumuladas por la cantidad total de tokens SPORE hipotecados en el contrato. Por lo tanto, cuando la cantidad total de tokens SPORE en el contrato ZABUFarm se reduce a un valor extremadamente bajo, sin duda ser calculado Un gran valor de bonificación.

4. El atacante obtuvo una gran cantidad de recompensas de tokens ZABU a través del contrato de ataque 1 que se había hipotecado previamente en ZABUFarm y luego vendió los tokens ZABU.

Este ataque fue causado por la incompatibilidad entre el modelo de hipoteca de ZabuFinance y los tokens SPORE. Ha habido muchos ataques causados ​​por tales problemas. El cambio de token real del contrato antes y después de la transferencia, en lugar de depender de la cantidad de tokens de hipoteca pasados ​​por el usuario. [2021/9/12 23:19:21]