S0_Arquitectura - SofiAlfonso/croody_web3_project GitHub Wiki
Diseño de la Arquitectura
1. Alcance del MVP
El MVP cubre las 3 funcionalidades del reto:
| # | Funcionalidad | Qué incluye |
|---|---|---|
| 1 | Wallet | Conectar wallet existente (MetaMask), ver saldo del token propio en tiempo real, enviar tokens P2P |
| 2 | NFTs | Ver mis NFTs, enviar NFTs a otro usuario, recibir NFTs |
| 3 | Subastas | Publicar NFT en subasta, pujar, tiempo límite, transferencia automática del NFT al ganador y pago al vendedor |
Se despliega sobre Ethereum Sepolia Testnet (no se usan costos reales de gas).
2. Dimensiones del sistema y Requisitos No Funcionales
| Dimensión | Valor |
|---|---|
| Usuarios concurrentes | 10 - 50 (contexto académico) |
| Tiempo de carga del frontend | < 2 segundos |
| Tiempo de confirmación en blockchain | ~15-30 seg (Sepolia) |
| Peticiones JSON-RPC por segundo | ~10-30 (lectura de saldos, NFTs, subastas) |
| Tamaño máximo de metadata NFT en IPFS | < 10 MB por activo |
Requisitos No Funcionales
| RNF | Descripción |
|---|---|
| Seguridad | La plataforma nunca accede a llaves privadas. El usuario firma todo desde su propia wallet (MetaMask). Los contratos usan protección contra reentrancia. |
| Descentralización | La lógica del negocio vive en los smart contracts y los metadatos en IPFS. |
| Usabilidad | Conexión de wallet en un clic vía RainbowKit. Interfaz clara con feedback del estado de transacciones. |
| Compatibilidad | Chrome, Brave o Firefox con MetaMask instalado. |
3. Modelado del Dominio
Entidades
| Entidad | Descripción | Atributos clave |
|---|---|---|
| User | No es un registro en blockchain, es la dirección de la wallet que se conecta | address |
| ProjectToken | Token propio del proyecto (ERC-20), se usa como moneda para pujar y pagar | balance, symbol, decimals |
| NFT | Coleccionable digital (ERC-721) con metadatos almacenados en IPFS | tokenId, owner, tokenURI, metadata |
| Auction | Subasta de un NFT con precio base, tiempo límite y pujas | auctionId, seller, tokenId, startPrice, highestBid, highestBidder, endTime, isActive |
| Bid | Puja de un usuario sobre una subasta | bidder, amount, timestamp |
Relaciones
User (address)
├── tiene saldo de ──▶ ProjectToken (uno)
├── es dueño de ──▶ NFT (cero o varios)
├── crea ──▶ Auction (pone su NFT en subasta)
└── hace ──▶ Bid (puja en una subasta)
NFT ── se publica en ──▶ Auction
Auction ── recibe ──▶ Bid (varias pujas)
Auction ── se paga con ──▶ ProjectToken
Al cerrar la Auction:
NFT ──▶ se transfiere al highestBidder
ProjectToken ──▶ se transfiere al seller

4. Descripción de Componentes
| Componente | Qué hace | Tecnología |
|---|---|---|
| Frontend | Interfaz web donde el usuario ve su saldo, NFTs y subastas | Next.js 16, React 19, TypeScript, Tailwind CSS |
| Web3 Provider | Conecta la wallet existente del usuario con la DApp | Wagmi + RainbowKit |
| ProjectToken | Contrato del token propio. Permite consultar saldo, transferir P2P y aprobar gasto para subastas | Solidity 0.8.24 (Hardhat), OpenZeppelin ERC20 |
| NFTCollection | Contrato de los NFTs. Gestiona propiedad, transferencias y referencia a metadatos | Solidity 0.8.24 (Hardhat), OpenZeppelin ERC721 |
| NFTMarketplace | Contrato de las subastas. Crear subasta, pujar, cerrar subasta con transferencia automática | Solidity 0.8.24 (Hardhat), OpenZeppelin ReentrancyGuard |
| IPFS | Almacena las imágenes y metadatos JSON de los NFTs fuera de la blockchain | IPFS |
5. Diagrama de Componentes

Justificación del diseño
Se optó por no usar un backend centralizado para la lógica de negocio (subastas, transferencias, tokens) ya que todo eso se resuelve directamente en los smart contracts y el frontend se comunica con la blockchain via JSON-RPC.
Se usan wallets externas (MetaMask) porque así no nos toca gestionar llaves privadas ni asumir esa responsabilidad; el usuario ya las tiene y las controla.
Se separaron 3 contratos independientes (token, NFTs, subastas) en vez de meter todo en uno, para que si algo falla en uno no afecte a los demás.
Los metadatos de los NFTs van a IPFS porque guardar imágenes directamente en la blockchain sería muy costoso en gas.
Se eligió Solidity como lenguaje de contratos porque es el estándar de Ethereum y tiene buena documentación, y Hardhat como entorno de desarrollo porque permite compilar, probar y desplegar todo desde un solo lugar.