--- title: "¿Qué es el estándar de tokens ERC-4626?" description: "Explora el nuevo estándar de tokenización de vaults y cómo implementarlo en tus proyectos de DeFi" --- # ¿Qué es el estándar de tokens ERC-4626? Si bien actualmente existen un par de estándares de tokens prominentes, el mundo de las [Finanzas Descentralizadas \(DeFi\)](https://www.alchemy.com/overviews/guide-to-defi) todavía tiene un problema recurrente respecto a los vaults tokenizados. Esto llevó a la creación del más reciente estándar llamado ERC-4626. Este artículo explicará qué son los vaults, los problemas que enfrentan los desarrolladores al tokenizarlos, y cómo ERC-4626 resuelve este problema en el desarrollo de DeFi. Luego profundizaremos en los nuevos cambios que trae este estándar y te mostraremos cómo implementarlos en tus smart contracts. ## **¿Qué es un vault?** Un vault es una solución multi-sig o smart contract que puede almacenar y gestionar activos como criptomonedas. Cada vault siempre cuenta con los tokens que genera como una forma de retorno. Estos tokens generados pueden luego intercambiarse por los tokens que originalmente estaban bloqueados en los vaults. Por ejemplo, cuando haces staking de Sushi en Sushiswap, que es un automated market maker \(AMM\), recibirás xSushi como recompensa. De manera similar, también recibirás cUSDC cuando hagas yield farming con el stablecoin USDC en [Compound](https://www.alchemy.com/dapps/compound), un protocolo DeFi de préstamos. cUSDC y xSushi son tokens que generan rendimiento (yield-bearing tokens), los cuales puedes canjear a cambio del token original \(por ejemplo, USDC o SUSHI en este caso\). El valor de los yield-bearing tokens siempre aumentará en la medida en que aumenten los tokens bloqueados en el vault o pool. Se percibe que los vaults son mejores y más seguros que las wallets, y esa es la razón por la que muchos protocolos DeFi eligen depositar sus fondos en un vault. Entre los protocolos DeFi populares que usan vaults se encuentran Sushiswap, [Aave](https://www.alchemy.com/dapps/aave), [Balancer](https://www.alchemy.com/dapps/balancer) y Compound, entre otros. ## **¿Cuál es el problema de tokenizar vaults?** El problema que enfrentan los desarrolladores respecto a los yield-bearing tokens es la integración de tokens de diferentes protocolos. Por ejemplo, en una situación en la que quieras [construir una app DeFi](https://www.alchemy.com/docs/alchemy-quickstart-guide) donde necesites integrar los tokens de cada protocolo, tendrás que investigar cada uno, conocer su modelo de acumulación de rendimientos, y adaptarlo a tu código base. Si quieres integrar vDAI de Maker DAO, stETH en Curve, y así sucesivamente, necesitarás entender las particularidades de sus smart contracts y construir soluciones personalizadas para integrar exitosamente cada uno de ellos en tu app DeFi. Además de lo estresante y demandante en tiempo que puede ser este proceso de integrar diferentes yield-bearing tokens, también aumenta el riesgo del smart contract debido a posibles errores. Los desarrolladores necesitarán dedicar más tiempo a revisar posibles vulnerabilidades en los adapters, y en algunos casos, incluso podrían necesitar contratar a auditores de smart contracts externos, lo cual puede resultar bastante costoso. Esto es más importante ahora que los atacantes están vulnerando la integridad de muchos protocolos y apps DeFi. ## **¿Quién creó el estándar ERC-4626?** Hacia finales de 2021, al notar lo difícil que resultaba para los desarrolladores integrar yield-bearing tokens separados, Joey Santoro—fundador de Fei Protocol—lideró a un equipo de otros cuatro desarrolladores de Ethereum para presentar la [**Ethereum Comment Proposal 4626**](https://eips.ethereum.org/EIPS/eip-4626) (ERC-4626). Después de pasar por varias rondas de revisión y deliberación, Ethereum finalmente aprobó el estándar en mayo de 2022. ## **¿Cuáles son los beneficios de ERC-4626 respecto a los vaults?** El principal beneficio de ERC-4626 es que estandariza los vaults tokenizados para facilitar la integración de protocolos y hacerla menos propensa a errores. Dado que existe un estándar común que se puede integrar, ya no hay necesidad real de construir adapters separados. En resumen, esto acelera el desarrollo; composabilidad al máximo nivel. De manera similar, reduce costos porque los builders ya no necesitan contratar auditores para ayudar con sus adapters e interfaces. Más importante aún, ERC-4626 mejora la seguridad entre las [apps](https://www.alchemy.com/dapps/top/defi-dapps) y los agregadores de yield que trabajan con yield-bearing tokens. ## ¿Qué cambios introduce el estándar ERC-4626? **Con el nuevo token ERC-4626, ahora existe un estándar para que los desarrolladores construyan apps DeFi que involucren yield tokens.** En resumen, el estándar ERC-4626 implementa las siguientes características: - una interfaz de vault optimizada para los desarrolladores que quieran integrarla. - otorga shares a cambio de depósitos, donde las shares representan la propiedad fraccionaria del token subyacente del vault - un estándar consistente con el cual los desarrolladores pueden trabajar al desarrollar contratos que generan rendimiento - seguridad probada en batalla para los tokens del vault ## **Cómo funciona ERC-4626: funciones y eventos** ERC-4626 es una extensión de y compatible con el estándar [ERC-20](https://www.alchemy.com/docs/how-to-interact-with-erc-20-tokens-in-solidity). Como resultado, la mayoría de las variables, eventos y funciones habituales que aplican en los contratos de tokens ERC-20 siguen funcionando con el estándar de vault ERC-4626. El estándar de vault introduce el concepto de _shares_ como una forma de obtener propiedad fraccionaria de todo el pool. Estas _shares_ se refieren a los yield-bearing tokens. Ahora comencemos a desarrollar en ERC-4626. Si bien puedes usar lenguajes como Cairo y Viper, escribiremos este contrato con [Solidity](https://www.alchemy.com/overviews/solidity). ### **1. Importa las extensiones de OpenZepellin a tu IDE** Después de haber abierto tu IDE—recomendamos Remix—indícale al compilador la versión de Solidity con la que estás escribiendo el contrato. En este caso, declara que trabajarás con 0.8. Después de eso, necesitarás importar dos extensiones de [OpenZeppelin](https://www.alchemy.com/dapps/openzeppelin), tanto de ERC-20 como de ERC-4626. A continuación, creemos un contrato y démosle un nombre. ### **2. Crea tu contrato** Nombra tu contrato y establece además que se basa tanto en el token ERC-20 como en ERC-4626. _Contract, testingVaults is ERC20, IERC4626 \{ tu código completo aquí\}_ ### **3. Implementa el estándar** Después de crear el contrato, hay algunos cambios importantes que debes conocer sobre los métodos, funciones y eventos de este estándar. Así, examinemos algunos de los métodos y eventos en ERC-4626: #### Deposit Cuando los usuarios ingresan fondos al vault, la función deposit activa al smart contract para que emita (mint) una cantidad correspondiente de shares al depositante. Como evento, el smart contract debe activarse cada vez que haya un depósito. Con esta función, hemos instruido al contrato para que deposite algunos tokens en el vault y otorgue la propiedad de las shares a quien realiza la llamada. Puedes escribir la función de retiro de la misma manera. #### **Withdrawal** La función withdrawal ayuda a los propietarios a quemar shares a cambio de assets. Cuando hay un retiro del vault, el evento withdrawal debe dispararse. El address indexed \_from en este evento representa al usuario que aprobó el depósito de tokens en el vault, mientras que la persona que puede retirar los tokens depositados es *the address indexed \_to*. #### Asset y totalAsset La dirección del token del vault debe usarse en la función _asset_. La cantidad total del asset subyacente en el smart contract debe declararse bajo *totalAssets*. #### convertToShares y convertToAssets Bajo el estándar ERC-4626, existen dos funciones de conversión: `convertToShares` y `convertToAssets`. Cuando necesites convertir assets a shares, `convertToShares` es la función correcta a llamar porque contiene la cantidad de shares a liberar en lugar de los assets. Por el contrario, `convertToAssets` funciona a la inversa, convirtiendo shares a assets. #### **Mint** La función mint se llama para el receiver una vez que hay un depósito. `maxMint` es la cantidad total de shares que se pueden crear para un usuario o receiver en un vault. Como desarrollador, debes configurar esto. #### **Redeem** La función `redeem` quema algunas shares del owner—msg.sender—y envía assets al receiver. Si por alguna razón las shares no pueden canjearse, `redeem` debe revertirse. `maxRedeem` es la cantidad de shares en el vault que el owner puede canjear. #### Preview Al usar los métodos preview, los desarrolladores deben tener en cuenta que los valores que estos métodos devuelven no serán del todo exactos, pero sí serán cercanos. No deberías depender de ellos como oráculos. Puedes usar preview junto con otros métodos como `mint`, `withdraw`, `redeem` y `deposit`. Y eso es todo. ¡Has comenzado exitosamente tu camino de desarrollo con ERC-4626! ## **Cerrando – el futuro de ERC-4626** Hay una nueva corriente en DeFi con la llegada de ERC-4626. Los agregadores de DeFi siempre encontraron bastante estresante agregar varios yield-bearing tokens porque no existía un estándar. Pero ahora ERC-4626 hace posible obtener detalles de yield-bearing tokens con una sola llamada a la API. El problema de tener que esforzarse extra para mejorar la seguridad de las aplicaciones DeFi con yield-bearing tokens se resuelve—en gran medida—con este estándar probado en batalla. El uso de la composabilidad y la interoperabilidad entre varios protocolos DeFi aumentará en los próximos años. Incluso es posible que este estándar sea una plataforma para construir y lanzar productos completamente nuevos en el ecosistema DeFi.