¿Qué es LUKSO?

LUKSO es una blockchain Layer 1 compatible con EVM que utiliza una versión no modificada de Ethereum. En términos prácticos, puede iniciarse (bootstrap) con cualquier cliente de Ethereum configurado para conectarse a la red de LUKSO, porque a nivel de red es fundamentalmente igual que Ethereum.

La diferencia no está en “reinventar Ethereum”, sino en sumar una capa de estándares y herramientas nuevas. LUKSO incorpora un conjunto de estándares de smart contracts llamados LUKSO Standards Proposals (LSPs), junto con herramientas que permiten crear protocolos y dApps innovadoras que, bajo estándares “viejos”, no pueden construirse de la misma forma.

🧱 LUKSO Standards Proposals (LSPs): los bloques de construcción

Los LSPs funcionan como el “lenguaje común” con el que LUKSO propone construir una nueva generación de aplicaciones. Dentro de este universo, el enfoque editorial suele organizarse en tres puntos:

🧱 Construir con estándares

Los LSPs sirven para:

• Descubrir los principales bloques de construcción de LUKSO.
• Entender los beneficios de usar esos estándares.
• Profundizar en las especificaciones que los definen.

🧬 Red, nodos y validadores

Además de los estándares, LUKSO incluye un camino para:

• Conectar una wallet a LUKSO Mainnet.
• Correr un nodo de LUKSO.
• Convertirse en validador.

Este componente es clave porque cualquier red Layer 1 necesita infraestructura, operación y consenso; LUKSO lo aborda sin romper compatibilidad con el ecosistema Ethereum.

✨ ¿Qué hace único a LUKSO?

La narrativa central de LUKSO se apoya en tres pilares: 🆙 Universal Profiles, 🪙 Tokens y 🌅 NFTs.

🆙 Universal Profiles

Los perfiles basados en smart contracts son presentados como una base esencial para mejorar la experiencia web3: cuentas más expresivas, configurables y capaces de representar identidad, permisos y comportamiento.

🪙 Tokens

LUKSO plantea tokens extensibles que van más allá del enfoque típico “solo DeFi”. Su tesis es que parte del futuro blockchain será más social, con activos capaces de interactuar con perfiles y notificaciones.

🌅 NFTs

Los NFTs se vuelven flexibles y extensibles, y además directamente componibles con Universal Profiles.

Dentro de este enfoque aparecen características que LUKSO resume como una lista de capacidades deseables y acumulables, por ejemplo: visual, upgradeable, security, gas-less, smart, extensible, safer; y, en el terreno de activos, conceptos como token icons, unlimited metadata, updatable, extensible, notifying, unified, authentic, better IDs, iterable, batch transfers.

🧠 ¿Por qué nuevos estándares?

LUKSO plantea que, al integrar distintos LSPs de formas únicas, se resuelven problemas fundamentales que frenan adopción o complican el uso cotidiano. La lógica se entiende mejor si se desglosa por objetivos.

👩‍🎤 Perfil on-chain estandarizado

Los usuarios pueden construir su perfil on-chain agregando imágenes, etiquetas, descripciones y links para moldear su identidad digital.

Además, estandarizar cuentas evita que la adopción se “atoré” por cambios impredecibles: si todas las aplicaciones siguen un comportamiento unificado, el desarrollo encima de la cuenta se vuelve consistente y confiable.

📝 Metadata actualizable y flexible

La metadata puede actualizarse. Esto habilita NFTs dinámicos: ciertas propiedades pueden cambiar con el tiempo, mientras otras permanecen inmutables.

📢 Notificaciones y capacidad de reacción

Para que una cuenta sea más interactiva y social, necesita poder recibir notificaciones y reaccionar ante acciones. En el diseño descrito, esto se logra emitiendo un evento único a la red con la acción notificada, que puede ser interpretado por interfaces y clientes off-chain.

⛽️ Experiencia gasless

Los Universal Profiles soportan Transaction Relay Services que cubren el gas de las transacciones del usuario. Así, el usuario no carga con el requisito de conseguir el token nativo “antes de poder empezar” a usar una app.

💫 Extender la cuenta con el tiempo

La cuenta puede ampliarse con el tiempo sin alterar código ni redeploy del smart contract asociado. Esto introduce una idea importante: la identidad/cuenta como software evolutivo, no como algo rígido.

🔓 Seguridad actualizable y control flexible

Los Universal Profiles pueden ser propiedad de un EOA o de un smart contract, por ejemplo un multisig. Eso permite control desde múltiples dispositivos y aplicaciones, con permisos distintos.

Este enfoque también habilita servicios como social recovery, apoyados en familia, amistades o dApps sin confianza (trustless).

🚦 Sistema de permisos

Un sistema robusto de permisos permite control granular sobre quién puede ejecutar acciones específicas dentro del contrato. Esto es crucial al manejar accesos en sistemas complejos con múltiples usuarios/roles, manteniendo permisos y restricciones dentro del propio perfil.

✍️ Multi Sig

El uso de multisig se presenta como una capa extra de seguridad para administrar la cuenta.

🪝 Hooks pre y post ejecución

Los hooks permiten ejecutar lógica adicional antes y después de la función principal. En Universal Profiles, esta capacidad se asocia con LSP20, habilitando casos de uso avanzados y mayor control del comportamiento contractual.

🇨🇭🔪 Multi-purpose

Un mismo contrato puede asumir varios roles: DAO, organización, marca, IA, robot, etc. La versatilidad del contrato y el modelo de permisos muestran por qué LUKSO insiste en que “la cuenta” no es solo una wallet, sino un contenedor de identidad y capacidades.

🧩 Problemas de los ERC “clásicos” que LUKSO busca resolver

LUKSO introduce estándares nuevos para atacar limitaciones de ERCs existentes, como:

• Riesgos en seguridad de approvals para tokens/NFTs.
• Metadata limitada.
• Falta de interoperabilidad (por ejemplo, ERC677, ERC777 y ERC1155 usan hooks de callback distintos para notificar transferencias).
• Fricción de onboarding por exigir que el usuario compre el token nativo para pagar gas desde el inicio.

En este marco, los LSP incluyen piezas como:

• universalReceiver (LSP1) para notificaciones.
• metadata flexible (ERC725Y).
• gestión segura de permisos (LSP6 Key Manager).
• transacciones gasless (LSP25 Execute Relay Call) para facilitar la incorporación de usuarios.

🧭 ¿Por qué LUKSO es Layer 1 y no “solo” una app en Ethereum?

El texto plantea que LUKSO se crea como Layer 1 para establecer su propio ecosistema, comunidad y aplicaciones, en lugar de construir encima de estándares congestionados de Ethereum. Aun así, por ser EVM-based (misma tecnología que Ethereum, sin modificar), LUKSO soporta herramientas de Ethereum y facilita que desarrolladores construyan y “porten” aplicaciones entre ambas redes.

🧰 Ventajas prácticas de los LSP para casos de uso reales

Los LSP se presentan como una caja de herramientas útil para almacenar datos en Universal Profiles, por ejemplo:

• Configuraciones de usuario de una dApp.
• Lista de assets recibidos.
• Lista de creadores de un activo digital.
• Seguidores (followers), permisos y más.

También habilitan:

• Transacciones gasless.
• Gestión de permisos fine-grained.

En conjunto, se argumenta que estos estándares permiten apps centradas en el usuario, con una experiencia inicial más amigable para quien no es técnico.

🧑‍💻 Universal Profiles: una “smart account” pensada para humanos

Un Universal Profile es una smart account con funciones de una wallet tradicional (como MetaMask), pero con énfasis en usabilidad y onboarding. Se describe como pensada para usuarios no técnicos y orientada a eliminar fricciones como:

• Manejo de llaves privadas.
• Pago de gas.
• Verificación de transacciones opacas antes de confirmar.

Además, suma capacidades avanzadas como permisos granulares para control multi-dispositivo.

🔌 ¿Cómo se conecta un Universal Profile a una dApp?

Se describe que puede conectarse “como cualquier otra wallet web3”, usando métodos como:

• EIP-6963,
• injected provider,
• multi-providers,
  y también mediante flujos tipo Sign-in with Ethereum (con un tutorial referido en el texto).

🗃️ Almacenamiento ilimitado: identidad, assets y más

Un Universal Profile puede guardar datos ilimitados de distintos tipos: assets, biografía, foto de perfil y portada, sitio web, links sociales, followers, permisos, configuraciones de dApps, música favorita, comunidades, etc. En esencia, puede almacenar y recuperar “cualquier cosa imaginable”.

🧾 ¿Cómo se leen esos datos?

Se indican dos rutas:

• Usar la función getData del contrato del Universal Profile y decodificar el valor.
• Usar librerías como erc725.js o lsp-utils.js, que realizan el decodificado de forma más sencilla.

✍️ ¿Cómo se actualizan esos datos?

Se mencionan tres vías:

• UP Browser Extension,
• una dApp con esa función,
• o programáticamente vía script (con guía referida).

🧯 Gasless desde el día uno (y también con opción de no usarlo)

Si el Universal Profile se creó vía universaleverything.io, el UP en la extensión del navegador puede permitir enviar transacciones gas-free automáticamente. Si no, se remite a documentación del relayer API para enviar transacciones al relayer, que las despacha y paga el gas.

⚙️ Importante: usar relayer no es obligatorio

El usuario puede optar por no depender del Transaction Relay Service y pagar el gas financiando el controlador del Universal Profile con moneda nativa (por ejemplo LYX).

🧱 ¿Qué fricciones elimina el gasless?

El texto describe que el usuario ya no necesita atravesar un proceso pesado como:

• descargar una wallet,
• crear una dirección,
• registrarse en un exchange para comprar cripto,
• hacer KYC,
• comprar el token nativo por tarjeta o transferencia,
• en algunos casos, pedir al banco que autorice la compra,
• y recién después empezar a usar dApps.

También se menciona que usuarios experimentados terminan comprando múltiples tokens nativos solo para “probar dApps” en varias redes; y que el bridging entre cadenas implica dejar fondos atrás. Incluso para desarrolladores, se señala que conseguir test LYX vía faucets puede requerir tener un mínimo en mainnet para evitar spam.

Finalmente, se agrega que, al soportar gasless, se pueden configurar múltiples relayers y cambiar entre ellos antes de confirmar una transacción.

🆚 Universal Profiles vs. otras smart wallets

A continuación, una síntesis fiel del comparativo incluido:

📊 Comparativa de funcionalidades (resumen)

• Profile-like information: Universal Profiles ✅ (vía LSP3), otros ❌
• Generic information storage: Universal Profiles ✅ (vía ERC725Y), otros ❌
• Notifications & reactability: Universal Profiles ✅ (vía LSP1), otros ❌
• Permission system: Universal Profiles ✅ (vía LSP6), otros ❌
• Multisig: Gnosis SAFE ✅; Universal Profiles 🔶 (puede ser controlado por multisig)
• Multi-purpose: Universal Profiles ✅ (puede ser DAO/organización/marca/IA/robot mediante permisos LSP6); otros 🔶 (con extensión futura)
• Gasless experience: todos ✅ (en el comparativo, Universal Profiles vía Transaction Relayer)
• Extensible: Universal Profiles ✅ (vía LSP17)
• Upgradeable security: Universal Profiles ✅ (vía LSP14)
• Pre y post execution hooks: Universal Profiles ✅ (vía LSP20)

🧷 Beneficios clave: “metadata en un solo lugar” y experiencia coherente

🗄️ Metadata en un solo lugar

Con wallets tradicionales, el usuario repite su información al registrarse en cada dApp (username, bio, redes sociales). En cambio, el Universal Profile guarda esos datos en un solo lugar (el storage del contrato), y cualquier dApp los lee desde ahí, acelerando onboarding.

Como ejemplo mencionado, se alude a interacciones con contratos (por ejemplo, mintear tokens o refinar burntpix) y a tres dApps diferentes (UniversalProfile.cloud, Universal.Page y UniversalSwaps.io) consumiendo los mismos datos del Universal Profile.

🎨 Metadata personalizable

El texto sostiene que un Universal Profile puede representar múltiples identidades:

• usuario personal/profesional,
• marca,
• DAO/organización,
• IA “viviendo” en internet,
• servicio como recuperación de wallet,
• personaje de videojuego (representado como NFT con su metadata).

También se mencionan ejemplos de cuatro perfiles usados con distintos propósitos: marca, DAO, usuario y servicio de recovery.

🔑 Multi-control con permisos

Un Universal Profile puede ser controlado por múltiples EOAs (y sus llaves privadas), permitiendo o restringiendo acciones mediante permisos. Esos controladores pueden vivir en laptop, escritorio, móvil, o hardware wallet (como Ledger) y también pueden ser dApps con permisos específicos.

Se dan ejemplos concretos:

• una dApp DeFi que solo transfiere un token específico a un pool específico,
• una dApp de música que solo actualiza playlists en el storage del perfil,
• un familiar con acceso de recuperación para recuperación confiable.

🪙 LSP7 y LSP8: tokens y NFTs más consistentes que ERC20/721

Se presentan dos estándares de activos:

• LSP7 Digital Asset
• LSP8 Identifiable Digital Asset

🧭 Guías de migración

Para quien ya tiene contratos en Ethereum, se mencionan guías prácticas:

• migrar de ERC20 a LSP7
• migrar de ERC721 a LSP8

⚖️ ERC20 vs. LSP7: autorización y transferencias

Resumen del comparativo incluido:

• Aprobación básica: ERC20 ✅ (approve/allowance), LSP7 ✅ (authorizeOperator con notificación al operador)
• Validación del receptor: ERC20 ❌, LSP7 ✅ (parámetro force + callbacks de receptor)
• Contexto de transferencia: ERC20 ❌, LSP7 ✅ (data opcional)
• Hooks de transferencia: ERC20 ❌, LSP7 ✅ (notificaciones LSP1 a emisor/receptor)
• Rechazo de transferencia: ERC20 ❌, LSP7 ✅ (receptores pueden rechazar vía Universal Receiver)
• Datos contextuales ricos: ERC20 ❌, LSP7 ✅

🧩 Beneficios destacados de LSP7/LSP8

• Funciones más simples para desarrolladores: mismo nombre de funciones para transfer y approvals, en vez de aprender funciones distintas para ERC20/721/1155.
• Metadata ilimitada y dinámica: tokens y NFTs pueden tener mucha más información, y esa información puede evolucionar con el tiempo.
• Batching flexible: distribuir múltiples tokens/NFTs con transferBatch(...) o agrupar acciones con batchCalls(...) (autorizar operadores, transferir y actualizar metadata).
• Notificaciones al transferir y al agregar operadores: emisor y receptor reciben notificación y pueden reaccionar.
• Nuevo flujo más seguro: se “termina” el patrón de approve(…) y luego transferFrom(…) como historia típica, reemplazándolo por reacciones y notificaciones con Universal Receiver.
• Extendabilidad por extensiones: se agregan nuevas capacidades con extensiones.
• Parámetro de seguridad por defecto: un bool force para reducir transferencias accidentales.

🧾 Detalles técnicos que cambian la vida al developer (sin exigirle aprender otra “cosa rara”)

🧮 Una sola función de transferencia, distinto tipo de parámetro

• En LSP7, transfer(address,address,uint256,bool,bytes) usa uint256 para cantidades.
• En LSP8, transfer(address,address,bytes32,bool,bytes) usa bytes32 como token ID.

Ambos usan authorizeOperator(address,[uint256/bytes32],bytes) para aprobar operadores, ya sea por cantidades o por IDs específicos.

🧬 Metadata ilimitada para tokens y NFTs

Se enumeran ejemplos de metadata posible:

• iconos e imagen,
• creadores del token/colección,
• lista de exchanges donde aparece el token.

Para LSP8, también se incluye metadata por NFT con setDataForTokenId(...) y setDataBatchForTokenIds(...), lo que permite colecciones más ricas, por ejemplo:

• ropa digital para avatares,
• armas/armaduras en videojuegos,
• NFTs dinámicos cuyos rasgos cambian según condiciones y triggers.

📢 Notificaciones y automatización con Universal Receiver Delegate

En cada transferencia, emisor y receptor son notificados. La notificación incluye un ID específico (typeIds) del tipo “envié” o “recibí”.

Además, pueden “enchufarse” contratos de lógica llamados Universal Receiver Delegate para reacciones automáticas, como:

• registrar/remover tokens de la lista de assets recibidos,
• bloquear spam tokens con lógica maliciosa mediante listas spam/blacklist,
• reenviar un porcentaje a un vault (ahorro) o a un familiar,
• distribuir dividendos/bonos proporcionalmente de forma trustless.

Se remarca que en web3 muchos contratos envían/reciben assets (🆙, vaults, marketplaces, liquidity pools), y que LSP1 Universal Receiver permite construir sistemas de automatización más seguros y cómodos encima de ellos.

✋🏻 El parámetro force para prevenir historias de terror

El transfer(...) en LSP7/LSP8 incluye un bool force para evitar transferencias accidentales, por ejemplo:

• pegar una dirección incorrecta en un input,
• pasar una dirección equivocada en una interacción compleja,
• enviar a un contrato sin funciones para mover tokens (tokens “atorados”),
• enviar a un EOA (caso para usuarios avanzados) que podría perder acceso por llaves/seed phrases.

El force busca asegurar que no se transfiera a direcciones que no puedan sostener o re-transferir el token.

🧾 Conclusión: LUKSO como “Ethereum compatible”, pero con reglas para una web3 más humana

LUKSO se presenta como una Layer 1 EVM-compatible que no compite “rompiendo Ethereum”, sino construyendo encima de su compatibilidad una propuesta distinta: estándares nuevos (LSPs) diseñados para identidad, UX y aplicaciones centradas en usuarios.

El hilo conductor de toda la arquitectura es claro: Universal Profiles como cuentas inteligentes con permisos granulares, notificaciones, extensiones, seguridad actualizable y opciones gasless; y, en paralelo, LSP7/LSP8 como estándares de activos que buscan ser más consistentes, flexibles y seguros que los flujos tradicionales de ERC. En conjunto, la ambición es mover la conversación de “wallets y contratos” a “perfiles, experiencias y automatización”, donde una cuenta no solo guarda fondos: guarda contexto, identidad y capacidades.

Si el objetivo histórico de web3 ha sido devolver propiedad y control al usuario, la propuesta de LUKSO intenta resolver un problema previo y más básico: que ese control sea usable desde el primer día, sin obligar a entender fricciones técnicas como gas, approvals opacos o configuraciones repetidas en cada app. En ese sentido, LUKSO no solo plantea una cadena: plantea un estándar de experiencia para que lo on-chain se sienta menos como un laboratorio y más como un producto listo para personas reales.