From e38d7fecd364769c3c8c1f171de8d791c0122136 Mon Sep 17 00:00:00 2001 From: guinoki Date: Tue, 30 Dec 2025 09:16:40 +0100 Subject: [PATCH 1/4] feat: add Spanish translation for README --- README.es.md | 361 +++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 +- 2 files changed, 362 insertions(+), 1 deletion(-) create mode 100644 README.es.md diff --git a/README.es.md b/README.es.md new file mode 100644 index 0000000..20f0723 --- /dev/null +++ b/README.es.md @@ -0,0 +1,361 @@ +# Auditorías de Seguridad de Smart Contracts de Pashov Audit Group + +[www.pashov.com](https://www.pashov.com/) + +Para solicitar una auditoría de seguridad de smart contracts de Pashov Audit Group, contáctame en [Telegram @pashovkrum](https://t.me/pashovkrum) + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Préstamos (Lending)

+ 		+ + Aave Logo + + + + + HyperLend Logo + + + + + HypurrFi Logo + + +
+

DEXs

+ 		+ + Uniswap Logo + + 3.2T+ Total Volume + + PancakeSwap Logo + 1.7T+ Total Volume + + + Sushi Logo + + 260B+ Total Volume +
+

Monedas Estables (Stablecoins)

+ 		+ + Ethena Logo + + + + + Falcon Logo + + + + + Resolv Logo + + +
+

Rendimiento (Yield)

+ 		+ + Euler Earn Logo + + + + + StakeDAO Logo + + + + + YieldBasis Logo + + +
+

Activos del Mundo Real (RWAs)

+ 		+ + Ostium Logo + + + + RAAC Logo + + + + Dinari Logo + + +
+

Otros

+ 		+ + LayerZero Logo + + 55B+ Total Bridge Volume + + + Pump Logo + + + + + Kinetiq Logo + + +
+ +
+ + + + + + + + + + + +## Todas las auditorías del equipo Pashov Audit Group + + +### DEX + +| Proyecto | Reporte | Etiquetas | +| ----------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | +| Uniswap | [2024-10-11](team/pdf/Uniswap-security-review-October.pdf) | | +| Sushi | `2025-01-21`, [2024-08-15](team/pdf/SushiSwap-security-review.pdf) | | +| KittenSwap | [2025-07-31](team/pdf/KittenSwap-security-review_2025-07-31.pdf), [2025-06-12](team/pdf/KittenSwap-security-review_2025-06-12.pdf)
[2025-05-07](team/pdf/KittenSwap-security-review_2025-05-07.pdf) | | +| Reya | [2024-10-25](team/pdf/Reya-security-review-October.pdf), [2024-08-03](team/pdf/ReyaNetwork-security-review-August.pdf)
[2024-07-15](team/pdf/ReyaNetwork-security-review-July.pdf), [2024-06-29](team/pdf/ReyaNetwork-security-review-June2.pdf)
[2024-06-02](team/pdf/ReyaNetwork-security-review-June.pdf), [2024-04-30](team/pdf/ReyaNetwork-security-review-April.pdf)
[2024-03-30](team/pdf/ReyaNetwork-security-review.pdf) | | +| Gains Network | [2025-05-26](team/pdf/GainsNetwork-security-review_2025-05-26.pdf), [2024-07-18](team/pdf/GainsNetwork-security-July2.pdf)
[2024-07-05](team/pdf/GainsNetwork-security-review-July.pdf), [2024-05-28](team/pdf/GainsNetwork-security-review-May.pdf)
[2024-02-23](team/pdf/GainsNetwork-security-review-February.pdf), [2023-12-12](team/pdf/GainsNetwork-security-review.pdf) | | +| Bunni | [2024-10-17](team/pdf/Bunni-security-review-October.pdf), [2024-08-19](team/pdf/Bunni-security-review-August.pdf) | | +| Solidly | `2024-04-15` | | +| 1inch | [2024-03-25](team/pdf/1inch-security-review.pdf) | | +| Burve | [2025-01-29](team/pdf/Burve-security-review_2025-01-29.pdf), [2025-03-05](team/pdf/Burve-security-review_2025-03-05.pdf) | | +| Wagmi | [2024-04-01](team/pdf/Wagmi-security-review.pdf) | | +| Hyperhyper | [2025-03-30](team/pdf/Hyperhyper-security-review_2025-03-30.pdf) | | +| Funnel | [2025-08-27](team/pdf/Funnel-security-review_2025-08-27.pdf) | | +| Ostium | [2025-04-06](team/pdf/Ostium-security-review_2025-04-06.pdf), [2025-01-21](team/pdf/Ostium-security-review_2025-01-21.pdf)
[2025-08-22](team/pdf/Ostium-security-review_2025-08-22.pdf) | | +| Lucidly | [2024-06-24](team/pdf/Lucidly-security-review-June.pdf), [2024-04-25](team/pdf/Lucidly-security-review.pdf) | | +| Increment | [2024-02-12](team/pdf/Increment-security-review.pdf) | | +| Sharwa Finance | [2024-06-17](team/pdf/SharwaFinance-security-review.pdf) | | +| Agora | [2025-06-05](team/pdf/AgoraStableSwap-security-review_2025-06-05.pdf) | | + + + + + + + +### Préstamos (Lending) + +| Proyecto | Reporte | Etiquetas | +| ---------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | +| Aave | [2024-09-05](team/pdf/Aave-security-review.pdf), [2025-11-29](team/pdf/Aave-security-review_2025-11-29.pdf) | | +| Hyperlend | [2025-01-11](team/pdf/Hyperlend-security-review_2025-01-11.pdf), [2025-11-21](team/pdf/Hyperlend-security-review_2025-11-21.pdf) | | +| Blueberry | [2025-05-16](team/pdf/Blueberry-security-review_2025-05-16.pdf), [2025-04-30](team/pdf/Blueberry-security-review_2025-04-30.pdf)
[2025-03-26](team/pdf/Blueberry-security-review_2025-03-26.pdf) [2025-03-12](team/pdf/Blueberry-security-review_2025-03-12.pdf) | | +| HypurrFi | [2025-02-12](team/pdf/HypurrFi-security-review_2025-02-12.pdf) | | +| Nucleus | [2024-12-14](team/pdf/Nucleus-security-review_2024-12-14.pdf) | | +| Ion | [2024-07-10](team/pdf/IonProtocol-security-review-July.pdf), [2024-04-29](team/pdf/IonProtocol-security-review.pdf) | | +| Enclave | [2025-10-25](team/pdf/Enclave-security-review_2025-10-25.pdf) | | + + + + +### Monedas Estables (Stablecoin) + +| Proyecto | Reporte | Etiquetas | +| ----------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | +| Resolv | [2025-07-25](team/pdf/Resolv-security-review_2025-07-25.pdf), [2025-05-14](team/pdf/Resolv-security-review_2025-05-14.pdf)
[2025-04-15](team/pdf/Resolv-security-review_2025-04-15.pdf), [2024-12-09](team/pdf/Resolv-security-review_2024-12-09.pdf)
[2024-10-10](team/pdf/Resolv-security-review-October.pdf), [2024-08-26](team/pdf/Resolv-security-review-August.pdf)
[2024-07-27](team/pdf/Resolv-security-review.pdf) | | +| Ethena | [2024-10-17](team/pdf/Ethena-security-review-October.pdf), [2024-08-31](team/pdf/Ethena-security-review-August.pdf)
[2024-05-20](team/pdf/Ethena-security-review-May.pdf), [2024-02-20](team/pdf/Ethena-security-review-february.pdf)
[2023-12-19](team/pdf/Ethena-security-review.pdf) | | +| Hyperstable | [2025-03-19](team/pdf/Hyperstable-security-review_2025-03-19.pdf), [2025-02-26](team/pdf/Hyperstable-security-review_2025-02-26.pdf)
[2025-06-03](team/pdf/Hyperstable-security-review_2025-06-03.pdf) | | +| USDV | [2025-03-06](team/pdf/USDV-security-review_2025-03-06.pdf) | | +| YuzuUSD | [2025-08-28](team/pdf/YuzuUSD-security-review_2025-08-28.pdf) | | +| Falcon | [2025-02-17](team/pdf/Falcon-security-review_2025-02-17.pdf) | | +| Roots | [2025-02-09](team/pdf/Roots-security-review_2025-02-09.pdf) | | +| Dinari | [2024-12-07](team/pdf/Dinari-security-review_2024-12-07.pdf) | | +| Ouroboros | [2024-12-06](team/pdf/Ouroboros-security-review_2024-12-06.pdf), [2025-06-30](team/pdf/Ouroboros-security-review_2025-06-30.pdf) | | +| DYAD | [2024-09-14](team/pdf/Dyad-security-review.pdf) | | +| Open Dollar | [2024-04-17](team/pdf/OpenDollar-security-review.pdf) | | +| Level | [2025-04-19](team/pdf/Level-security-review_2025-04-09.pdf) | | +| Tangent | [2025-10-30](team/pdf/Tangent-security-review_2025-10-30.pdf), [2025-12-08](team/pdf/Tangent-security-review_2025-12-08.pdf) | | + + + + +### Gestión de Activos (Asset Management) + +| Proyecto | Reporte | Etiquetas | +| ----------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | +| Euler Earn | [2025-07-25](team/pdf/EulerEarn-security-review_2025-07-25.pdf) | | +| YieldBasis | [2025-03-26](team/pdf/YieldBasis-security-review_2025-03-26.pdf) | | +| Stake DAO | [2025-07-21](team/pdf/StakeDAO-security-review_2025-07-21.pdf) | | +| Elixir | [2025-08-17](team/pdf/Elixir-security-review_2025-08-17.pdf) | | +| Reserve | [2025-06-02](team/pdf/Reserve-security-review_2025-06-02.pdf) | | +| Omo | [2025-01-25](team/pdf/Omo-security-review_2025-01-25.pdf) | | +| Cove | [2025-04-16](team/pdf/Cove-security-review_2025-04-16.pdf), [2024-12-30](team/pdf/Cove-security-review_2024-12-30.pdf) | | +| GammaSwap | [2024-12-30](team/pdf/GammaSwap-security-review_2024-12-30.pdf) | | +| Interpol | [2024-12-24](team/pdf/Interpol-security-review_2024-12-24.pdf), [2024-09-02](team/pdf/Interpol-security-review.pdf) | | +| Nexus | [2024-11-29](team/pdf/Nexus-security-review_2024-11-29.pdf) | | +| ULTI | [2024-11-25](team/pdf/ULTI-security-review-November2.pdf), [2024-11-11](team/pdf/ULTI-security-review-November.pdf) | | +| Peapods | [2024-11-16](team/pdf/Peapods-security-review_2024-11-16.pdf) | | +| Arcadia | [2024-10-24](team/pdf/Arcadia-security-review-October.pdf), [2024-01-08](team/pdf/Arcadia-security-review.pdf) | | +| Hydration | [2024-10-17](team/pdf/Hydration-security-review-October.pdf) | | +| TitanX | [2024-09-28](team/pdf/TitanX-security-review.pdf) | | +| Aegis | [2024-09-18](team/pdf/Aegis-security-review-September.pdf), [2024-08-12](team/pdf/AegisVault-security-review.pdf) | | +| Radiant | [2024-07-25](team/pdf/Radiant-security-review-July.pdf), [2024-06-30](team/pdf/Radiant-security-review-June.pdf)
[2024-02-28](team/pdf/Radiant-security-review.pdf) | | +| Hyperbloom | [2025-06-24](team/pdf/Hyperbloom-security-review_2025-06-24.pdf) | | +| Neutrl | [2025-03-27](team/pdf/Neutrl-security-review_2025-03-27.pdf) | | +| LoopVault | [2025-04-30](team/pdf/LoopVaults-security-review_2025-04-30.pdf) | | +| Fyde | [2024-05-27](team/pdf/Fyde-security-review-May.pdf), [2024-03-08](team/pdf/Fyde-security-review.pdf) | | +| Adapter | [2024-05-13](team/pdf/AdapterFinance-security-review.pdf) | | +| TapiocaDAO | [2024-02-12](team/pdf/TapiocaDAO-security-review-february.pdf), [2023-11-27](team/pdf/TapiocaDAO-security-review.pdf) | | +| Saffron | [2024-01-22](team/pdf/Saffron-security-review.pdf), [2025-07-31](team/pdf/Saffron-security-review_2025-07-31.pdf) | | + +### Recaudación de Fondos y Venta de Tokens (Fundraising & Tokensales) + +| Proyecto | Reporte | Etiquetas | +| -------------------------------------- | ---------------------------------------------------------------------- | -----------------------------------------------------------------------------------| +| Pump | `2025-04-28`, `2025-03-18`
`2024-10-11`, `2024-05-21`
`2024-03-03` , [2025-10-08](team/pdf/Pump-security-review_2025-10-08.pdf)
[2025-06-26](team/pdf/Pump-security-review_2025-06-26.pdf) , [2025-04-28](team/pdf/Pump-security-review_2025-04-28.pdf)
[2025-03-18](team/pdf/Pump-security-review_2025-03-18.pdf) | | +| DeFi App | [2025-01-08](team/pdf/DefiApp-security-review_2025-01-08.pdf) | | +| Aria Protocol | [2025-05-12](team/pdf/Aria-security-review_2025-05-12.pdf), [2025-04-25](team/pdf/Aria-security-review_2025-04-25.pdf) | | +| Desci | [2025-02-07](team/pdf/DesciLaunchpad-security-review_2025-02-07.pdf) | | +| Pump Science | [2024-12-24](team/pdf/PumpScience-security-review_2024-12-24.pdf) | | +| Stardusts | [2024-12-19](team/pdf/Stardusts-security-review_2024-12-19.pdf) | | +| g8keep | [2024-12-12](team/pdf/g8keep-security-review_2024-12-12.pdf), [2024-07-10](team/pdf/g8keep-security-review.pdf) | | +| Sofamon | [2024-08-12](team/pdf/Sofamon-security-review-August.pdf), [2024-02-26](team/pdf/Sofamon-security-review.pdf) | | +| Groupcoin | [2024-07-05](team/pdf/Groupcoin-security-review.pdf) | | +| Bio | [2024-06-13](team/pdf/Bio-security-review.pdf), [2025-12-15](team/pdf/Bio-security-review_2025-12-15.pdf) | | +| Serious | [2024-05-21](team/pdf/Serious-security-review.pdf) | | +| Aburra | [2024-05-20](team/pdf/Aburra-security-review.pdf) | | +| Catalyst | [2024-04-08](team/pdf/Catalyst-security-review-april.pdf), [2023-12-18](team/pdf/Catalyst-security-review.pdf) | | +| Pupniks | [2024-02-16](team/pdf/Pupniks-security-review.pdf) | | + +### Juegos (GameFi) + +| Proyecto | Reporte | Etiquetas | +| --------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | +| Coinflip | [2025-02-19](team/pdf/Coinflip-security-review_2025-02-19.pdf), [2025-02-05](team/pdf/Coinflip-security-review_2025-02-05.pdf) | | +| Rip It | [2025-05-10](team/pdf/RipIt-security-review_2025-05-10.pdf), [2025-04-25](team/pdf/RipIt-security-review_2025-04-25.pdf) | | +| Gacha | [2025-01-27](team/pdf/Gacha-security-review_2025-01-27.pdf) | | +| Cardex | [2025-01-21](team/pdf/Cardex-security-review_2025-01-21.pdf) | | +| Gigaverse | [2025-01-18](team/pdf/Gigaverse-security-review_2025-01-18.pdf) | | +| Primodium | [2024-10-02](team/pdf/Primodium-security-review_2024-10-02.pdf) | | +| Curio | [2024-07-23](team/pdf/Curio-security-review-July.pdf), [2024-04-15](team/pdf/Curio-security-review.pdf) | | +| HoneyJar | [2024-06-05](team/pdf/HoneyJar-security-review.pdf) | | + + + +### Otros + +| Proyecto | Reporte | Etiquetas | +| -------------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | +| Layer Zero – crosschain messaging | [2024-09-18](team/pdf/LZOrbit-security-review.pdf), [2024-09-18²](team/pdf/LZRateLimiter-security-review.pdf)
[2024-09-12](team/pdf/LayerZero-security-review-September.pdf), [2024-05-15](team/pdf/LayerZero-security-review.pdf) | | +| Starknet - staking | [2024-07-31](team/pdf/Starknet-security-review_2025-07-31.pdf) | | +| BOB – hybrid L2 | [2024-09-05](team/pdf/BOB-security-review-September.pdf), [2024-08-09](team/pdf/BOB-security-review-August.pdf)
[2024-06-24](team/pdf/BOB-security-review-June.pdf), [2024-04-19](team/pdf/BOB-USDCBridge-security-review.pdf)
[2024-04-19²](team/pdf/BOB-Onramp-security-review.pdf), [2025-03-17](team/pdf/BOB-security-review_2025-03-17.pdf)
[2025-10-18](team/pdf/BOB-Staking-security-review_2025-10-18.pdf) | | +| Karak – restaking | [2024-04-10](team/pdf/Karak-security-review.pdf), [2024-06-30](team/pdf/Karak-security-review-June.pdf) | | +| Kinetiq - liquid staking | [2025-02-26](team/pdf/Kinetiq-security-review_2025-02-26.pdf) | | +| Initia - widget and router API | [2024-06-17](team/pdf/Initia-security-review_2025-06-17.pdf) | | +| Gatekeeper - Solana sandwich validator control | [2025-06-28](team/pdf/Gatekeeper-security-review_2025-06-28.pdf) | | +| Itos - derivative engine | [2025-05-24](team/pdf/Itos-security-review_2025-05-24.pdf) | | +| Zipper – crosschain messaging | [2025-05-05](team/pdf/Zipper-security-review_2025-05-05.pdf) | | +| Spectra - interest rate derivatives | [2025-01-17](team/pdf/Spectra-security-review_2025-01-17.pdf), [2024-02-24](team/pdf/Spectra-security-review.pdf) | | +| Napier – Interest rate derivatives | [2025-09-30](team/pdf/Napier-security-review_2025-09-30.pdf) | | +| Veil – privacy service | [2025-02-12](team/pdf/VeilCash-security-review_2025-02-12.pdf) | | +| Ample Earn – Strategy Allocator | [2025-12-12](team/pdf/AmpleEarn-security-review_2025-12-12.pdf) | | +| Beam Nodes – cross-chain NFT minting | [2025-01-28](team/pdf/BeamNodes-security-review_2025-01-28.pdf) | | +| Azuro - prediction markets | [2024-02-20](team/pdf/Azuro_security_review.pdf) | | +| Memecoin Prediction Markets | [2025-08-07](team/pdf/MCP-security-review_2025-08-07.pdf) | | +| HYBUX - Token staking | [2025-11-11](team/pdf/HYBUX-security-review_2025-11-11.pdf) | | +| Clave - Account Abstraction | [2024-12-23](team/pdf/Clave-security-review_2024-12-23.pdf), [2024-11-02](team/pdf/Clave-security-review_2024-11-02.pdf) | | +| Rivus – liquid staking | [2024-10-28](team/pdf/Rivus-security-review-October.pdf), [2025-05-13](team/pdf/Rivus-security-review.pdf) | | +| apDAO – DAO | [2024-10-03](team/pdf/apDAO-security-review_2024-10-03.pdf) | | +| Cryptex – synthetic asset | [2024-09-30](team/pdf/Cryptex-security-review.pdf) | | +| ZROClaim – token claim | [2024-06-05](team/pdf/LayerZeroZROClaim-security-review.pdf) | | +| Klaster - Account Abstraction | [2024-06-13](team/pdf/Klaster-security-review.pdf) | | +| StationX – community ownership | [2024-06-05](team/pdf/StationX-security-review.pdf) | | +| Noodles – Bonding curve for X accounts | [2025-03-11](team/pdf/Noodles-security-review_2025-03-11.pdf) | | +| Mass - Account Abstraction | [2024-03-18](team/pdf/Mass-security-review.pdf) | | +| SXT - Token distribution and staking | [2024-03-31](team/pdf/SXT-security-review_2025-03-31.pdf) | | +| Subsquid - distributed query engine | [2024-01-29](team/pdf/Subsquid-security-review.pdf) | | +| Covenant - Risk Tranching Protocol | [2025-08-18](team/pdf/Covenant-security-review_2025-08-18.pdf) | | +| BiconomyNexus - Account Abstraction | [2025-03-21](team/pdf/BiconomyNexus-security-review_2025-03-21.pdf) | | +| BiconomyComposability - Transaction Builder | [2025-03-22](team/pdf/BiconomyComposability-security-review_2025-03-22.pdf) | | +| stHype - Liquid Staking | [2025-10-13](team/pdf/stHYPE-security-review_2025-10-13.pdf), [2025-11-10](team/pdf/stHYPE-security-review_2025-11-10.pdf) | | +| Tanssi - Interaction toolkit and Bridge | [2025-04-30](team/pdf/Tanssi-security-review_2025-04-30.pdf) | | +| Regnum Aurum - RWA Tokenization | [2025-04-30](team/pdf/RegnumAurum-security-review_2025-08-12.pdf) | | +| Elytra - Liquid Restaking | [2025-07-10](team/pdf/Elytra-security-review_2025-07-10.pdf), [2025-07-27](team/pdf/Elytra-security-review_2025-07-27.pdf) | | diff --git a/README.md b/README.md index 7c25c77..ea89ecd 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Pashov Audit Group Smart Contract Security Audits -[www.pashov.com](https://www.pashov.com/) +[www.pashov.com](https://www.pashov.com/) | [🇪🇸 Leer en Español](README.es.md) Reach out for a Pashov Audit Group smart contract security audit to me on [Telegram @pashovkrum](https://t.me/pashovkrum) From 844409088de442b8ac8c5d4393b3183951053a88 Mon Sep 17 00:00:00 2001 From: guinoki Date: Tue, 30 Dec 2025 09:21:46 +0100 Subject: [PATCH 2/4] docs: add mission statement to Spanish README --- README.es.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.es.md b/README.es.md index 20f0723..ef0ab62 100644 --- a/README.es.md +++ b/README.es.md @@ -2,6 +2,8 @@ [www.pashov.com](https://www.pashov.com/) +> **En la misión de asegurar $1,000,000,000,000 en criptoactivos.** + Para solicitar una auditoría de seguridad de smart contracts de Pashov Audit Group, contáctame en [Telegram @pashovkrum](https://t.me/pashovkrum) From 8585a8304985b806382c7437ac3c3644b8518f17 Mon Sep 17 00:00:00 2001 From: guinoki Date: Tue, 30 Dec 2025 09:31:18 +0100 Subject: [PATCH 3/4] feat: add Spanish translation for Uniswap report --- README.es.md | 2 +- team/md/Uniswap-security-review-October.es.md | 213 ++++++++++++++++++ 2 files changed, 214 insertions(+), 1 deletion(-) create mode 100644 team/md/Uniswap-security-review-October.es.md diff --git a/README.es.md b/README.es.md index ef0ab62..103ff15 100644 --- a/README.es.md +++ b/README.es.md @@ -199,7 +199,7 @@ Para solicitar una auditoría de seguridad de smart contracts de Pashov Audit Gr | Proyecto | Reporte | Etiquetas | | ----------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -| Uniswap | [2024-10-11](team/pdf/Uniswap-security-review-October.pdf) | | +| Uniswap | [2024-10-11](team/md/Uniswap-security-review-October.es.md) | | | Sushi | `2025-01-21`, [2024-08-15](team/pdf/SushiSwap-security-review.pdf) | | | KittenSwap | [2025-07-31](team/pdf/KittenSwap-security-review_2025-07-31.pdf), [2025-06-12](team/pdf/KittenSwap-security-review_2025-06-12.pdf)
[2025-05-07](team/pdf/KittenSwap-security-review_2025-05-07.pdf) | | | Reya | [2024-10-25](team/pdf/Reya-security-review-October.pdf), [2024-08-03](team/pdf/ReyaNetwork-security-review-August.pdf)
[2024-07-15](team/pdf/ReyaNetwork-security-review-July.pdf), [2024-06-29](team/pdf/ReyaNetwork-security-review-June2.pdf)
[2024-06-02](team/pdf/ReyaNetwork-security-review-June.pdf), [2024-04-30](team/pdf/ReyaNetwork-security-review-April.pdf)
[2024-03-30](team/pdf/ReyaNetwork-security-review.pdf) | | diff --git a/team/md/Uniswap-security-review-October.es.md b/team/md/Uniswap-security-review-October.es.md new file mode 100644 index 0000000..ff08e88 --- /dev/null +++ b/team/md/Uniswap-security-review-October.es.md @@ -0,0 +1,213 @@ +# Acerca de + +Pashov Audit Group está formado por múltiples equipos de algunos de los mejores investigadores de seguridad de contratos inteligentes en el espacio. Con un recuento combinado de vulnerabilidades de seguridad reportadas de más de 1000, el grupo se esfuerza por crear el mejor viaje de auditoría posible: aunque nunca se puede garantizar una seguridad del 100%, garantizamos los mejores esfuerzos de nuestros investigadores experimentados para su protocolo blockchain. Revisa nuestro trabajo anterior [aquí](https://github.com/pashov/audits) o contáctanos en Twitter [@pashovkrum](https://twitter.com/pashovkrum). + +# Descargo de Responsabilidad + +Una revisión de seguridad de contratos inteligentes nunca puede verificar la ausencia total de vulnerabilidades. Este es un esfuerzo limitado por tiempo, recursos y experiencia donde intentamos encontrar tantas vulnerabilidades como sea posible. No podemos garantizar una seguridad del 100% después de la revisión o incluso que la revisión encuentre algún problema con sus contratos inteligentes. Se recomiendan encarecidamente revisiones de seguridad posteriores, programas de recompensas por errores (bug bounties) y monitoreo on-chain. + +# Introducción + +Una revisión de seguridad con tiempo limitado del repositorio **timeless-fi/bunni-v2** fue realizada por **Pashov Audit Group**, con un enfoque en los aspectos de seguridad de la implementación de los contratos inteligentes de la aplicación. + +# Acerca de Uniswap V4 Periphery + +Uniswap v4 conserva las mejoras de eficiencia de capital de Uniswap v3, al tiempo que introduce flexibilidad a través de hooks y optimiza el uso de gas en todo el proceso. El contrato SVG en los contratos periféricos define una biblioteca llamada NFTSVG, que proporciona funciones para generar imágenes SVG utilizadas en los NFTs de Uniswap, combinando elementos gráficos personalizables como curvas, colores y posiciones basadas en varios parámetros como IDs de tokens, rangos de precios y símbolos de tokens. + +# Clasificación de Riesgos + +| Severidad | Impacto: Alto | Impacto: Medio | Impacto: Bajo | +| ---------------------- | ------------ | -------------- | ----------- | +| **Probabilidad: Alta** | Crítica | Alta | Media | +| **Probabilidad: Media**| Alta | Media | Baja | +| **Probabilidad: Baja** | Media | Baja | Baja | + +## Impacto + +- Alto - conduce a una pérdida material significativa de activos en el protocolo o daña significativamente a un grupo de usuarios. + +- Medio - conduce a una pérdida material moderada de activos en el protocolo o daña moderadamente a un grupo de usuarios. + +- Bajo - conduce a una pérdida material menor de activos en el protocolo o daña a un pequeño grupo de usuarios. + +## Probabilidad + +- Alta - la ruta de ataque es posible con suposiciones razonables que imitan las condiciones on-chain, y el costo del ataque es relativamente bajo en comparación con la cantidad de fondos que se pueden robar o perder. + +- Media - solo un vector de ataque condicionalmente incentivado, pero aún relativamente probable. + +- Baja - tiene demasiadas suposiciones o muy improbables o requiere una participación significativa por parte del atacante con poco o ningún incentivo. + +## Acción requerida para niveles de severidad + +- Crítica - Debe arreglarse lo antes posible (si ya está desplegado) + +- Alta - Debe arreglarse (antes del despliegue si aún no está desplegado) + +- Media - Debería arreglarse + +- Baja - Podría arreglarse + +# Resumen de la Evaluación de Seguridad + +_review commit hash_ - [7faae4718eecda1b33dc3abd894431ed2d16c929](https://github.com/timeless-fi/bunni-v2/tree/7faae4718eecda1b33dc3abd894431ed2d16c929) + +_fixes review commit hash_ - [1a21920085fc712ca745361bf397e8a7be25dc1c](https://github.com/timeless-fi/bunni-v2/tree/1a21920085fc712ca745361bf397e8a7be25dc1c) + +### Alcance + +Los siguientes contratos inteligentes estuvieron dentro del alcance de la auditoría: + +- `PositionDescriptor` +- `PositionManager` +- `ERC721Permit_v4` +- `SafeCurrencyMetadata` +- `AddressStringUtils` +- `HexStrings` +- `Descriptor` +- `SVG` +- `SafeCurrencyMetadata` + +# Hallazgos + +# [M-01] La dirección del Hook no se representa correctamente en el SVG + +## Severidad + +**Impacto:** Bajo + +**Probabilidad:** Alta + +## Descripción + +La función `generateSVGPositionDataAndLocationCurve` de la biblioteca `SVG` genera el SVG para los datos de la posición. Estos datos incluyen la dirección del contrato hook, que no se representa completa, sino solo los primeros y últimos caracteres con puntos suspensivos en el medio. + +Para procesar la dirección del hook, primero se llama a la función `toHexString` para transformar la dirección en una cadena, por lo que la variable `hookStr` tiene 42 caracteres de longitud y el rango de sus índices de bytes es de 0 a 41. + +Luego, la dirección cortada se genera concatenando los primeros 5 caracteres, los puntos suspensivos y los últimos 3 caracteres de la variable `hookStr`. Sin embargo, los valores pasados a la función `substring` son incorrectos para los últimos caracteres, ya que `endIndex` debería ser 42 en lugar de 40. + +```solidity + function generateSVGPositionDataAndLocationCurve( + string memory tokenId, + address hook, + int24 tickLower, + int24 tickUpper + ) private pure returns (string memory svg) { +@> string memory hookStr = (uint256(uint160(hook))).toHexString(20); + string memory tickLowerStr = tickToString(tickLower); + string memory tickUpperStr = tickToString(tickUpper); + uint256 str1length = bytes(tokenId).length + 4; +@> string memory hookSlice = string(abi.encodePacked(substring(hookStr, 0, 5), "...", substring(hookStr, 37, 40))); +``` + +Esto significa que si la dirección del hook es `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`, el SVG mostrará el siguiente texto: + +``` +Hook: 0xa0b...6eb +``` + +Esto resultará en que los usuarios no puedan identificar el contrato hook. + +## Recomendaciones + +```diff +- string memory hookSlice = string(abi.encodePacked(substring(hookStr, 0, 5), "...", substring(hookStr, 37, 40))); ++ string memory hookSlice = string(abi.encodePacked(substring(hookStr, 0, 5), "...", substring(hookStr, 39, 42))); +``` + +# [L-01] La dirección del Hook podría no estar establecida + +En `Descriptor.sol` y `SVG.sol` parece que existe la expectativa de que cada posición tendrá un contrato hook asociado, sin embargo, como se indica en [esta página](https://docs.uniswap.org/contracts/v4/concepts/hooks), los hooks son opcionales para los pools de liquidez, por lo que las posiciones pueden no tener un hook asociado. + +Por ejemplo, los SVGs que se generan en `SVG.sol` podrían ser confusos para los usuarios que tienen posiciones en pools de liquidez sin un contrato hook. En los SVGs generados actualmente habrá secciones que se verán algo así como `Hook: 0x0000...0000`. Para el usuario no educado, podría parecer que el SVG se generó incorrectamente o que el hook está de hecho en la dirección mostrada. + +Sería mejor si hubiera una lógica condicional para cuando una posición no tiene un hook asociado. Algunas posibilidades incluyen: + +- Generar SVGs (o descriptores) sin secciones específicas de hooks si el pool de liquidez relevante no utiliza un contrato hook. +- En lugar de mostrar `0x0000...00000` mostrar una cadena como `No hook` (Sin hook). + +Por supuesto, podría ser más fácil/mejor quedarse con la dirección 0 para algunos componentes como URIs que necesitan confirmarse con un formato específico esperado. Sin embargo, para el contenido visible por el usuario, sería mejor ser más transparente/explícito. + +# [L-02] Cambio disruptivo en los hashes de permiso (permit hashes) + +Aunque v4 aún no se ha desplegado en mainnet, se ha desplegado en testnet, por lo que vale la pena mencionar que el pequeño cambio en la cadena de nombre en `PositionManager.sol` de `V4` a `v4` romperá todos los permisos existentes que han sido firmados pero no utilizados aún. Esto puede afectar a cualquier integrador que esté probando con v4. + +Si este cambio se entiende y se comunica a cualquier integrador de testnet posterior, entonces este cambio puede persistir. + +# [L-03] Usar la dirección cero para el token nativo puede ser confuso para los usuarios finales + +Internamente, Uniswap v4 utiliza la dirección cero para representar el token nativo de la cadena. Esto significa que `tokenURI` para los NFTs de pools que usan el token nativo contendrá el siguiente texto en el campo "description" de sus metadatos: + +``` +ETH Address: 0x0000000000000000000000000000000000000000 +``` + +De la misma manera, la imagen SVG para el NFT contendrá el siguiente texto en el borde de la imagen: + +``` +0x0000000000000000000000000000000000000000 • ETH +``` + +Esto podría ser confuso para los usuarios finales, ya que podrían interpretar la dirección cero como la dirección real del token nativo. + +Considere gestionar el caso especial de que la moneda sea el token nativo y no mostrar la dirección en ese caso o usar una representación diferente, como la palabra "Native" (Nativo). + +# [L-04] Caracteres especiales no escapados pueden producir JSON inválido + +El `Descriptor.constructTokenURI` genera un JSON codificado en Base64 que será devuelto por la función `PositionDescriptor.tokenURI`. La función no sanitiza completamente los símbolos de entrada, que pueden contener caracteres especiales que producirán un JSON inválido. + +Los siguientes caracteres deben escaparse de la misma manera que se hace para el carácter de comillas dobles: + +- `\u000c` (form feed - salto de página) +- `\n` (newline - salto de línea) +- `\r` (carriage return - retorno de carro) +- `\t` (tab - tabulación) + +# [L-05] Cadenas de símbolos largas pueden causar que `tokenURI` revierta o artefactos en la imagen SVG + +La función `currencySymbol` en la biblioteca `SafeCurrencyMetadata` se utiliza para extraer el símbolo del token del contrato del token. Si el valor devuelto por el contrato es demasiado largo, puede causar los siguientes problemas: + +1. Si la longitud del símbolo es mayor a 255 caracteres, la función `Descriptor.escapeQuotes` revertirá debido a un error de desbordamiento (overflow), ya que `symbolBytes.length` no cabrá en un `uint8`: + +```solidity + for (uint8 i = 0; i < symbolBytes.length; i++) { + if (symbolBytes[i] == '"') { + quotesCount++; + } + } +``` + +2. Para longitudes inferiores a 255 pero aún largas, el texto con los datos de los tokens colocado en el borde de la imagen SVG se superpondrá y la salida será ilegible ([ver ejemplo](https://raw.githubusercontent.com/gist/shaka0x/3261ae647d8ad1a004e6512d72a04dc5/raw/b7f9e9294d2c1a4710d7db59eab89081182e4b83/nft.svg)). + +Considere recortar la salida de la función `currencySymbol` a una longitud sensata para evitar estos problemas. + +# [L-06] `currencyDecimals` no comprueba si el valor devuelto es uint8 + +En `SafeCurrencyMetadata`, el NatSpec de la función `currencyDecimals` establece lo siguiente: + +```solidity +/// @notice attempts to extract the token decimals, returns 0 if not implemented or not a uint8 +``` + +Sin embargo, la función no comprueba si el valor devuelto por el contrato del token es un uint8, por lo que en caso de que el valor sea mayor a 255, la función revertirá en la fase de decodificación: + +```solidity + if (data.length == 32) { + return abi.decode(data, (uint8)); + } +``` + +Aunque un valor decimal mayor a 255 podría no esperarse, ya que no es posible representar un número con más de 77 decimales en 32 bytes, la función debería evitar revertir y devolver el valor de respaldo de 0 en su lugar. + +Considere agregar los siguientes cambios al código: + +```diff + if (data.length == 32) { +- return abi.decode(data, (uint8)); ++ uint256 decimals = abi.decode(data, (uint256)); ++ if (decimals <= type(uint8).max) { ++ return uint8(decimals); ++ } + } + return (false, 0); +``` From 07f7b5fe41943d69351988c676e5f34c3f4f2c8c Mon Sep 17 00:00:00 2001 From: guinoki Date: Tue, 30 Dec 2025 09:35:32 +0100 Subject: [PATCH 4/4] feat: add Spanish translation for Aave report --- README.es.md | 2 +- team/md/Aave-security-review.es.md | 370 +++++++++++++++++++++++++++++ 2 files changed, 371 insertions(+), 1 deletion(-) create mode 100644 team/md/Aave-security-review.es.md diff --git a/README.es.md b/README.es.md index 103ff15..f41931b 100644 --- a/README.es.md +++ b/README.es.md @@ -227,7 +227,7 @@ Para solicitar una auditoría de seguridad de smart contracts de Pashov Audit Gr | Proyecto | Reporte | Etiquetas | | ---------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -| Aave | [2024-09-05](team/pdf/Aave-security-review.pdf), [2025-11-29](team/pdf/Aave-security-review_2025-11-29.pdf) | | +| Aave | [2024-09-05](team/md/Aave-security-review.es.md), [2025-11-29](team/pdf/Aave-security-review_2025-11-29.pdf) | | | Hyperlend | [2025-01-11](team/pdf/Hyperlend-security-review_2025-01-11.pdf), [2025-11-21](team/pdf/Hyperlend-security-review_2025-11-21.pdf) | | | Blueberry | [2025-05-16](team/pdf/Blueberry-security-review_2025-05-16.pdf), [2025-04-30](team/pdf/Blueberry-security-review_2025-04-30.pdf)
[2025-03-26](team/pdf/Blueberry-security-review_2025-03-26.pdf) [2025-03-12](team/pdf/Blueberry-security-review_2025-03-12.pdf) | | | HypurrFi | [2025-02-12](team/pdf/HypurrFi-security-review_2025-02-12.pdf) | | diff --git a/team/md/Aave-security-review.es.md b/team/md/Aave-security-review.es.md new file mode 100644 index 0000000..d1612ec --- /dev/null +++ b/team/md/Aave-security-review.es.md @@ -0,0 +1,370 @@ +# Acerca de + +Pashov Audit Group está formado por múltiples equipos de algunos de los mejores investigadores de seguridad de contratos inteligentes en el espacio. Con un recuento combinado de vulnerabilidades de seguridad reportadas de más de 1000, el grupo se esfuerza por crear el mejor viaje de auditoría posible: aunque nunca se puede garantizar una seguridad del 100%, garantizamos los mejores esfuerzos de nuestros investigadores experimentados para su protocolo blockchain. Revisa nuestro trabajo anterior [aquí](https://github.com/pashov/audits) o contáctanos en Twitter [@pashovkrum](https://twitter.com/pashovkrum). + +# Descargo de Responsabilidad + +Una revisión de seguridad de contratos inteligentes nunca puede verificar la ausencia total de vulnerabilidades. Este es un esfuerzo limitado por tiempo, recursos y experiencia donde intentamos encontrar tantas vulnerabilidades como sea posible. No podemos garantizar una seguridad del 100% después de la revisión o incluso que la revisión encuentre algún problema con sus contratos inteligentes. Se recomiendan encarecidamente revisiones de seguridad posteriores, programas de recompensas por errores (bug bounties) y monitoreo on-chain. + +# Introducción + +Una revisión de seguridad con tiempo limitado del repositorio **bgd-labs/aave-v3-origin-pashov** fue realizada por **Pashov Audit Group**, con un enfoque en los aspectos de seguridad de la implementación de los contratos inteligentes de la aplicación. + +# Acerca de Aave V3.2 + +El Protocolo Aave es un sistema descentralizado donde los usuarios pueden suministrar liquidez para ganar intereses, tomar prestados activos con más garantía de la que piden prestada, o participar en liquidaciones. Aave v3 introdujo eMode, que permite a los usuarios agrupar activos relacionados, como ETH y WETH, para configuraciones de mayor riesgo, pero cada activo solo podía pertenecer a un eMode, limitando la flexibilidad. La actualización Aave v3.2 introduce eModes líquidos, permitiendo que los activos sean parte de múltiples eModes con configuraciones más detalladas, como si un activo puede ser prestado o usado como garantía dentro de un eMode, y nuevas opciones de configuración ofrecen un control más granular sobre el uso de activos en diferentes eModes. + +# Clasificación de Riesgos + +| Severidad | Impacto: Alto | Impacto: Medio | Impacto: Bajo | +| ---------------------- | ------------ | -------------- | ----------- | +| **Probabilidad: Alta** | Crítica | Alta | Media | +| **Probabilidad: Media**| Alta | Media | Baja | +| **Probabilidad: Baja** | Media | Baja | Baja | + +## Impacto + +- Alto - conduce a una pérdida material significativa de activos en el protocolo o daña significativamente a un grupo de usuarios. + +- Medio - conduce a una pérdida material moderada de activos en el protocolo o daña moderadamente a un grupo de usuarios. + +- Bajo - conduce a una pérdida material menor de activos en el protocolo o daña a un pequeño grupo de usuarios. + +## Probabilidad + +- Alta - la ruta de ataque es posible con suposiciones razonables que imitan las condiciones on-chain, y el costo del ataque es relativamente bajo en comparación con la cantidad de fondos que se pueden robar o perder. + +- Media - solo un vector de ataque condicionalmente incentivado, pero aún relativamente probable. + +- Baja - tiene demasiadas suposiciones o muy improbables o requiere una participación significativa por parte del atacante con poco o ningún incentivo. + +## Acción requerida para niveles de severidad + +- Crítica - Debe arreglarse lo antes posible (si ya está desplegado) + +- Alta - Debe arreglarse (antes del despliegue si aún no está desplegado) + +- Media - Debería arreglarse + +- Baja - Podría arreglarse + +# Resumen de la Evaluación de Seguridad + +_review commit hash_ - [a4849111a0ce57e3af1ca5cd9a9b8c6a8cdad1e0](https://github.com/bgd-labs/aave-v3-origin-pashov/tree/a4849111a0ce57e3af1ca5cd9a9b8c6a8cdad1e0) + +_fixes review commit hash_ - [dd0bbecb90a53628fe15c076217eac3a7275182f](https://github.com/bgd-labs/aave-v3-origin-pashov/tree/dd0bbecb90a53628fe15c076217eac3a7275182f) + +### Alcance + +Los siguientes contratos inteligentes estuvieron dentro del alcance de la auditoría: + +- `AaveProtocolDataProvider` +- `IPoolConfigurator` +- `IPoolDataProvider` +- `EModeConfiguration` +- `ReserveConfiguration` +- `Errors` +- `ConfiguratorLogic` +- `EModeLogic` +- `GenericLogic` +- `LiquidationLogic` +- `ValidationLogic` +- `DataTypes` +- `PoolConfigurator` + +### Vectores de ataque cubiertos + +#### 1. LTV y Umbral de Liquidación Subóptimos + +##### Descripción + +Un atacante intenta manipular la selección de activos para aprovechar tasas subóptimas en E-Mode, ganando potencialmente términos más favorables de lo previsto. ¿Podría el nuevo EMode resultar inesperadamente en un LTV o umbral de liquidación más bajo que el modo predeterminado? O, cuando los usuarios habilitan EMode, ¿obtienen LTV y umbrales de liquidación subóptimos debido a nuevas suposiciones? + +##### Protección + +El sistema siempre utiliza los parámetros más conservadores (seguros) entre E-Mode y el modo regular para cada activo, asegurando que los usuarios no puedan explotar discrepancias para obtener ventajas injustas. Que el LT de EMode sea siempre mayor que el LT sin eMode para todos los activos no es una restricción, por lo que no es un problema. Para LTV y umbrales de liquidación subóptimos, no se indica en la documentación pero es el comportamiento previsto. + +#### 2. Persistencia de Parámetros de E-Mode + +##### Descripción + +Un atacante intenta adelantarse (front-run) a la eliminación de un activo de un E-Mode para bloquear parámetros favorables de LTV y umbral de liquidación. + +##### Protección + +Los parámetros de E-Mode se aplican dinámicamente durante los cálculos del factor de salud. Incluso si un activo se elimina de E-Mode, el sistema utilizará los parámetros del modo regular para ese activo, evitando la explotación de configuraciones de E-Mode obsoletas. + +#### 3. Liquidaciones Instantáneas al Eliminar Garantía (Collateral) + +##### Descripción + +Un atacante intenta explotar el período de transición cuando la garantía se elimina de E-Mode, desencadenando potencialmente liquidaciones injustas. + +##### Protección + +El sistema requiere que el factor de salud permanezca por encima de 1 al cambiar de E-Modes o cuando cambian los parámetros de E-Mode. Esto asegura que las posiciones permanezcan saludables durante las transiciones, evitando liquidaciones instantáneas. + +#### 4. Manejo Asimétrico de Préstamos y Garantías + +##### Descripción + +Un atacante intenta aprovechar la diferencia en el tratamiento entre los activos prestados y la garantía en E-Mode para crear una posición explotable. + +##### Protección + +El sistema aplica reglas consistentes tanto para préstamos como para garantías dentro de E-Mode. Los activos deben estar explícitamente habilitados para ambas funciones en E-Mode, y siempre se utilizan los parámetros más conservadores, evitando la explotación de asimetrías. + +#### 5. Riesgo de Corrupción de Almacenamiento Debido a Nuevas Variables + +##### Descripción + +Existe un riesgo de corrupción de almacenamiento debido a los cambios en la estructura `EModeCategory`, particularmente con la introducción de nuevas variables como `isCollateralBitmap` y `isBorrowableBitmap`. + +##### Protección + +Las nuevas variables son totalmente compatibles con el diseño de almacenamiento anterior, y no ocurre corrupción de datos. El sistema asegura que esto siga siendo cierto, asumiendo que Aave no ha establecido una dirección distinta de cero en el campo `priceSource` dentro de `EModeCategory`. + +#### 6. Corrupción de Datos Inducida por el Administrador + +##### Descripción + +Un administrador podría corromper sin saberlo la estructura de datos al cambiar el Loan-to-Value (LTV), Umbral de Liquidación (LT) o Bono de Liquidación (LB) para un eMode. + +##### Protección + +Los administradores pueden ajustar de forma segura LTV, LT o LB sin causar ninguna corrupción a los campos de datos `isCollateralBitmap` y `isBorrowableBitmap`. La arquitectura del sistema asegura la integridad de estos campos durante los cambios administrativos. + +#### 7. Deshabilitación de Categoría E-Mode + +##### Descripción + +Un atacante intenta explotar una categoría E-Mode activa pero no deseada que no se puede deshabilitar fácilmente, manipulando potencialmente el sistema a su favor. + +##### Protección + +El sistema está diseñado para operar de forma segura incluso con categorías E-Mode activas. Deshabilitar una categoría E-Mode es una operación sensible que requiere una consideración cuidadosa de las posiciones existentes, haciendo que sea intencionalmente difícil para prevenir consecuencias no deseadas. + +#### 8. Granularidad Limitada en la Gestión de Riesgos + +##### Descripción + +Un atacante intenta explotar la aplicación amplia de parámetros de E-Mode en todos los activos dentro de una categoría, encontrando potencialmente casos extremos donde se subestima el riesgo. + +##### Protección + +Aunque los parámetros de E-Mode se aplican ampliamente a una categoría, el sistema aún considera los parámetros de activos individuales. Utiliza la opción más conservadora entre E-Mode y los parámetros de activos individuales, asegurando que el riesgo no se subestime para ningún activo específico. + +#### 9. Precedencia de Parámetros de E-Mode + +##### Descripción + +Un atacante intenta manipular la interacción entre los parámetros globales de activos y los parámetros de E-Mode para crear una posición más favorable de lo previsto. + +##### Protección + +El sistema tiene reglas de precedencia claras, utilizando siempre la opción más conservadora entre parámetros globales y de E-Mode. Esto asegura que siempre se aplique el enfoque de gestión de riesgos más estricto, evitando la explotación de interacciones de parámetros. + +#### 10. La secuencia de Cambios de Configuración de EMode + +##### Descripción + +Encontrar todas las secuencias posibles de cambios de configuración de EMode, acciones de usuario y estados de usuario que no tengan en cuenta esta actualización actual. (por ejemplo, EMode ya activado, queriendo desactivar EMode, queriendo pedir prestado, ya prestado, queriendo proporcionar garantía, garantía ya proporcionada, queriendo liquidar) + +##### Protección + +Ya existen comprobaciones y salvaguardas para asegurar que todas las operaciones sean correctas. Todas las operaciones dependen de la misma validación dentro de `ValidationLogic`, por lo que actualizar las salvaguardas en un lugar asegura que todas las operaciones sigan siendo correctas. + +#### 11. Consecuencias No Deseadas de Cambios en EMode durante Préstamos + +##### Descripción + +¿Hay alguna consecuencia no deseada si los usuarios cambian EMode mientras tienen un activo prestado (por ejemplo, liquidable instantáneamente, no liquidable, garantía no contada, etc.)? + +##### Protección + +`ValidationLogic` y `calculateUserAccountData` dentro de `GenericLogic` ya están actualizados correctamente, por lo que no hay consecuencias no deseadas. + +#### 12. Impacto de la Eliminación de Activos Prestados de EMode + +##### Descripción + +¿Pueden los usuarios seguir beneficiándose de EMode una vez que un activo prestado se elimina de EMode, dado que `calculateUserAccountData` no verifica si el activo prestado está registrado en EMode? + +##### Protección + +Es posible, pero los desarrolladores afirman que es por diseño: "Deshabilitar el préstamo es una acción muy poco intrusiva, dentro y fuera de eMode. +Las posiciones existentes permanecen intactas, la gente simplemente ya no puede aumentar su exposición a través de mayores préstamos." + +#### 13. Eludir Restricciones de EMode con Flash Loans + +##### Descripción + +¿Pueden los usuarios eludir alguna restricción de EMode aprovechando los flash loans, por ejemplo, tomando prestados activos que no están registrados dentro de su EMode configurado? + +##### Protección + +Cuando los usuarios utilizan un flash loan y eligen no pagar los activos prestados, `BorrowLogic.executeBorrow` ya está en su lugar para asegurar que los activos prestados sean válidos, incluyendo la validación de EMode. + +#### 14. Manipulación del Bono de Liquidación de EMode + +##### Descripción + +EMode tiene un umbral de liquidación y un bono de liquidación separados. No usar ambos valores de EMode puede causar problemas graves para el protocolo. ¿Pueden los prestatarios manipular o cambiar el bono de liquidación de EMode? + +##### Protección + +`LiquidationLogic` tiene la misma verificación de estado exacta al decidir si los usuarios están utilizando el bono de liquidación de EMode que `GenericLogic.calculateUserAccountData`. Por lo tanto, ambos (el bono de liquidación y el umbral de liquidación) siempre usarán valores de EMode o no EMode. + +#### 15. Impacto Lógico en el Alcance de la Actualización de EMode + +##### Descripción + +¿Hay alguna operación existente que deba considerar este nuevo comportamiento pero que actualmente no lo haga? Comprobando toda la lógica dentro del alcance que no tiene diferencias dentro del commit. + +##### Protección + +Todas ellas (lógica dentro del alcance que no tiene diferencias dentro del commit), si no interactúan o dependen de la configuración de EMode, ya están usando `ValidationLogic`. Por lo tanto, son seguras y no requieren ningún cambio. + +#### 16. Impacto de EMode en Otras Características + +##### Descripción + +¿El nuevo EMode impacta inesperadamente otras características (por ejemplo, Préstamos Aislados - Siloed Borrowing, Modo de Aislamiento - Isolation Mode, etc.)? Por ejemplo, ¿activar EMode deshabilita accidentalmente otras características o modos? + +##### Protección + +Las salvaguardas y validaciones para cada característica son independientes dentro de sus respectivas bibliotecas y `ValidationLogic`, por lo que no hay impacto. + +#### 17. Manejo de Casos eMode = 0 + +##### Descripción + +¿Se manejan correctamente todos los casos donde eMode = 0? eMode = 0 es el caso predeterminado, así que asegúrese de que no haya funciones o lógica que accedan accidentalmente a eMode = 0 y utilicen el LTV y umbral de liquidación de EMode del usuario. Además, asegúrese de que no sea posible que un administrador configure eMode = 0. + +##### Protección + +Las funciones dentro de `ValidationLogic` y `GenericLogic` ya excluyen eMode = 0 (asegurando `params.userEModeCategory != 0`), y `configureEModeCategory` ya asegura que los cambios de configuración a eMode = 0 estén restringidos (asegurando `id != 0`). + +#### 18. Llamadas Simultáneas a Funciones de Administrador + +##### Descripción + +Dos administradores pueden intentar llamar a las funciones `setCollateral` y `setBorrowable` simultáneamente con los mismos argumentos, potencialmente corrompiendo el estado final. + +##### Protección + +Tanto `setCollateral` como `setBorrowable` son funciones idempotentes, lo que significa que múltiples llamadas con los mismos parámetros no cambiarán el estado final. Esto evita cualquier cambio de estado no deseado por transacciones repetidas de diferentes administradores. + +#### 19. Disminución del Factor de Salud por Cambio de EMode + +##### Descripción + +Un usuario podría intentar cambiar su eMode, disminuyendo sin saberlo el HF (Health Factor), resultando en una liquidación instantánea. + +##### Protección + +El sistema verifica el Factor de Salud (HF) después de permitir que cualquier usuario cambie su eMode. Si el Factor de Salud cae por debajo de 1 como resultado del cambio, la acción se bloquea, asegurando que los usuarios no puedan hacerlo. + +#### 20. Riesgo de Corrupción de Datos y Eliminación de Máscara eMode + +##### Descripción + +La eliminación de la máscara eMode dentro del mapa de bits de configuración de activos podría conducir potencialmente a la corrupción de datos. + +##### Protección + +La máscara eMode se ha eliminado limpiamente sin afectar el resto de los datos almacenados en el mapa de bits, asegurando que no haya corrupción de datos ni efectos secundarios no deseados. + +#### 21. Impacto de la Actualización de EMode en Usuarios Existentes + +##### Descripción + +Los usuarios actualmente en un eMode específico pueden experimentar problemas o explotar cambios introducidos por la actualización. + +##### Protección + +Los usuarios en eMode no se ven afectados por la actualización. El mapeo que rastrea los eModes de los usuarios (`_usersEModeCategory`) permanece sin cambios. Además, siempre que los valores de LTs y LTVs se mantengan, las funciones `calculateUserAccountData` y `executeLiquidationCall` se comportarán como antes de la actualización. + +#### 22. Riesgo de Desbordamiento en `setCollateral()` + +##### Descripción + +Desbordamiento en la función `setCollateral()` al establecer la variable `bit`. + +##### Protección + +Este problema se mitiga ya que el reserveIndex se valida para asegurar que siempre sea menor que 128. + +#### 23. Riesgo de Colisión de Ranura de Almacenamiento en Biblioteca `DataTypes` + +##### Descripción + +Colisión de ranura de almacenamiento en la biblioteca DataTypes. + +##### Protección + +Las ranuras de almacenamiento se gestionan adecuadamente para prevenir colisiones. + +# Hallazgos + +# [L-01] `setUserEMode` debería comprobar si `categoryId` es el mismo para evitar validación innecesaria + +Cuando el usuario llama a `setUserEmode`, la ejecución no comprueba si el `categoryId` proporcionado es el mismo que la configuración anterior del usuario. Esto requerirá que los usuarios realicen una validación innecesaria del factor de salud y gasten gas extra. Comparado con cuando los usuarios llaman a `setUserUseReserveAsCollateral` para configurar una reserva como garantía, este retornará antes si la bandera proporcionada es la misma que la bandera existente. + +```solidity + function executeUseReserveAsCollateral( + mapping(address => DataTypes.ReserveData) storage reservesData, + mapping(uint256 => address) storage reservesList, + mapping(uint8 => DataTypes.EModeCategory) storage eModeCategories, + DataTypes.UserConfigurationMap storage userConfig, + address asset, + bool useAsCollateral, + uint256 reservesCount, + address priceOracle, + uint8 userEModeCategory + ) external { + DataTypes.ReserveData storage reserve = reservesData[asset]; + DataTypes.ReserveCache memory reserveCache = reserve.cache(); + + uint256 userBalance = IERC20(reserveCache.aTokenAddress).balanceOf(msg.sender); + + ValidationLogic.validateSetUseReserveAsCollateral(reserveCache, userBalance); + +>>> if (useAsCollateral == userConfig.isUsingAsCollateral(reserve.id)) return; + // ... +} +``` + +Considere usar el mismo patrón dentro de `setUserEmode` / `executeSetUserEMode`. Si la categoría proporcionada es la misma que la existente, retornar antes para evitar validación innecesaria. + +```diff + function executeSetUserEMode( + mapping(address => DataTypes.ReserveData) storage reservesData, + mapping(uint256 => address) storage reservesList, + mapping(uint8 => DataTypes.EModeCategory) storage eModeCategories, + mapping(address => uint8) storage usersEModeCategory, + DataTypes.UserConfigurationMap storage userConfig, + DataTypes.ExecuteSetUserEModeParams memory params + ) external { + ValidationLogic.validateSetUserEMode( + eModeCategories, + userConfig, + params.reservesCount, + params.categoryId + ); + ++ if (usersEModeCategory[msg.sender] == params.categoryId) return; + usersEModeCategory[msg.sender] = params.categoryId; + ValidationLogic.validateHealthFactor( + reservesData, + reservesList, + eModeCategories, + userConfig, + msg.sender, + params.categoryId, + params.reservesCount, + params.oracle + ); + emit UserEModeSet(msg.sender, params.categoryId); + } +```