¿Qué es una smart wallet? Cuentas inteligentes, abstracción de cuentas y flujos de trabajo onchain

Definición y alcance de una smart wallet

Una smart wallet es una cuenta cripto cuya dirección onchain está controlada por un contrato inteligente. El contrato, no una clave privada simple, decide si una acción propuesta está autorizada. Ese contrato puede aceptar firmas de una passkey, de una o más claves, de un conjunto de guardianes o de cualquier lógica que definan sus autores. La aplicación de wallet que ve el usuario es un cliente que prepara solicitudes; la autoridad reside en el contrato desplegado.

Esto es diferente de una cuenta de propiedad externa (EOA) convencional, como una dirección de MetaMask o de una wallet de hardware. Una EOA está controlada por exactamente una clave privada, y cada transacción debe ser firmada por esa clave. Una smart wallet puede seguir siendo de autocustodia, pero la custodia se expresa como lógica de contrato y configuración de firmantes en lugar de como un único secreto.

El término también se usa para carteras físicas con bloqueo RFID o rastreadores. Esa es una categoría de producto diferente y queda fuera del alcance de este artículo. Esta guía cubre el significado cripto: cuentas de contrato inteligente, a menudo llamadas cuentas inteligentes, y los estándares de abstracción de cuentas que las hacen utilizables.

• EOA: una clave, un esquema de firma, un firmante.
• Smart wallet: un contrato que valida operaciones de usuario y puede aplicar políticas.
• Cuenta inteligente: la instancia onchain del contrato que posee activos y ejecuta llamadas.

Suposiciones y requisitos previos

Los procedimientos a continuación asumen que tienes un endpoint RPC compatible con EVM, una dirección de cuenta inteligente desplegada y la dirección del contrato EntryPoint para la versión de abstracción de cuentas que estás probando. No necesitas una cuenta con fondos para leer el estado, pero sí necesitas una cuenta con fondos o un bundler con patrocinio para enviar operaciones de usuario.

Mantén los secretos fuera de los archivos fuente. Usa variables de entorno como RPC_URL y PRIVATE_KEY, y nunca las confirmes en el repositorio. Para cargas de trabajo en producción, usa un endpoint gestionado en lugar de uno público; las páginas del servicio API de OnFinality y de precios de RPC describen las opciones de endpoint, y el directorio de redes enumera las cadenas compatibles.

export RPC_URL="https://your-endpoint.example"
export SMART_ACCOUNT="0xYourSmartAccountAddress"
export ENTRYPOINT="0xEntryPointAddress"
export PRIVATE_KEY="0x..."

Cómo ejecuta una smart wallet una operación de usuario

Según ERC-4337, el usuario no envía una transacción normal directamente. En su lugar, el cliente de la wallet construye una UserOperation: una estructura que contiene el remitente (la cuenta inteligente), un nonce, datos de llamada, límites de gas, parámetros de comisión y una firma. Un bundler recopila estas operaciones, las simula y las envía en una transacción a un contrato EntryPoint único.

El EntryPoint llama a la función de validación de la cuenta inteligente. Esa función decide si la firma es aceptable. Si la validación pasa, el EntryPoint ejecuta los datos de llamada de la cuenta. Dado que la validación es código de contrato, la cuenta puede aceptar aserciones de passkey WebAuthn, aprobaciones multifirma, claves de sesión con alcances o pruebas de recuperación social.

Los paymasters son contratos opcionales que pueden patrocinar el gas o aceptar el pago en un token ERC-20. Por eso una smart wallet puede parecer sin gas para el usuario final: un paymaster, una aplicación o un patrocinador cubre la comisión en el token nativo, y el usuario nunca tiene que poseer ETH u otra moneda de gas.

• Remitente: la dirección de la cuenta inteligente.
• Nonce: gestionado por el EntryPoint para ordenar las operaciones.
• CallData: la acción que debe realizar la cuenta.
• Campos del paymaster: quién paga y en qué activo.
• Firma: interpretada por la lógica de validación de la cuenta.

Leer el estado de una cuenta inteligente a través de RPC

Antes de confiar en cualquier interfaz de wallet, verifica la cuenta onchain. Las siguientes llamadas curl usan métodos JSON-RPC disponibles en endpoints EVM estándar. Reemplaza RPC_URL con tu endpoint. La primera llamada confirma que existe código en la dirección; una smart wallet debe tener bytecode. La segunda lee el saldo de la cuenta.

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["'"$SMART_ACCOUNT"'","latest"]}'

curl -s "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["'"$SMART_ACCOUNT"'","latest"]}'

Verificar una operación de usuario con JavaScript

El siguiente script usa ethers para inspeccionar el EntryPoint y la cuenta inteligente. Comprueba que el EntryPoint tiene código, lee el nonce de la cuenta desde el EntryPoint e imprime el resultado. Esto es un diagnóstico, no un cliente de bundler completo; confirma el cableado antes de enviar nada.

Instala las dependencias con npm install ethers y luego ejecuta el script con node. Si la llamada al nonce se revierte, es posible que la cuenta no esté registrada con ese EntryPoint, o que estés consultando la versión incorrecta del EntryPoint.

import { JsonRpcProvider, Contract, formatEther } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const account = process.env.SMART_ACCOUNT;
const entryPoint = process.env.ENTRYPOINT;

const code = await provider.getCode(account);
console.log("account has code:", code !== "0x");

const epCode = await provider.getCode(entryPoint);
console.log("entrypoint has code:", epCode !== "0x");

const balance = await provider.getBalance(account);
console.log("native balance:", formatEther(balance));

const ep = new Contract(entryPoint, [
  "function getNonce(address sender, uint192 key) view returns (uint256)"
], provider);

try {
  const nonce = await ep.getNonce(account, 0);
  console.log("entrypoint nonce:", nonce.toString());
} catch (err) {
  console.error("nonce read failed:", err.shortMessage || err.message);
}

Resultados esperados de la verificación

Una cuenta inteligente configurada correctamente devuelve una cadena de bytecode no vacía de eth_getCode, un saldo numérico y un nonce del EntryPoint. Si la cuenta nunca ha enviado una operación, el nonce suele ser cero. Si la dirección del EntryPoint es incorrecta, la llamada al nonce se revierte o devuelve datos vacíos.

Registra tus observaciones en una tabla para poder comparar entornos. La siguiente tabla es una plantilla; complétala con valores de tus propias ejecuciones en lugar de asumir números.

• | Comprobación | Método | Esperado | Observado |
• | Código de la cuenta | eth_getCode | no vacío | |
• | Código del EntryPoint | eth_getCode | no vacío | |
• | Saldo nativo | eth_getBalance | numérico | |
• | Nonce | getNonce | uint256 | |

Solución de problemas comunes de smart wallets

La mayoría de los fallos se agrupan en cuatro categorías: red incorrecta, versión incorrecta del EntryPoint, fallo de validación de firma y rechazo de gas o del paymaster. Aíslalos en ese orden. Primero confirma que el chain ID del endpoint RPC coincide con la cadena donde está desplegada la cuenta. Una cuenta inteligente desplegada en una cadena no tiene código en otra a menos que también se haya desplegado allí.

Segundo, confirma que la dirección del EntryPoint coincide con la implementación de la cuenta. ERC-4337 v0.6 y v0.7 usan direcciones de EntryPoint diferentes y diseños de estructura diferentes. Mezclarlos produce reversiones de validación que parecen errores de firma.

Tercero, revisa el formato de la firma. Las cuentas con passkey esperan aserciones WebAuthn, no firmas ECDSA. Las cuentas multifirma esperan el umbral configurado. Cuarto, revisa la política del paymaster: el patrocinio puede estar limitado por listas de permitidos, ventanas de tiempo o cuotas por usuario.

• Discrepancia de cadena: compara eth_chainId con la cadena de despliegue.
• Discrepancia de EntryPoint: verifica la dirección con la documentación de la cuenta.
• Discrepancia de firma: confirma el tipo de firmante y la codificación.
• Rechazo del paymaster: lee el error del bundler y la política del paymaster.

Ventajas y desventajas: smart wallets frente a EOA y wallets de hardware

Las smart wallets mejoran la incorporación y la recuperación, pero añaden piezas móviles. Una operación de usuario depende de un bundler, un EntryPoint y, a menudo, un paymaster. Cada uno es una consideración de disponibilidad y confianza. Las cuentas de contrato también cuestan más gas de despliegue y validación que una única firma ECDSA.

Las wallets de hardware siguen siendo sólidas para el almacenamiento en frío porque la clave nunca sale del dispositivo. Una smart wallet puede complementar a un firmante de hardware convirtiéndolo en uno de varios firmantes, pero no hace que la configuración sea automáticamente más segura. La seguridad depende de la lógica de validación, el conjunto de firmantes y la política de recuperación.

Para los equipos, la pregunta práctica es operativa: ¿quién ejecuta el bundler, quién patrocina el gas y cómo se gestionan las actualizaciones? Si la cuenta es actualizable, la autoridad de actualización es una suposición de confianza crítica. Documéntala antes de mantener un valor significativo.

Elegir infraestructura para probar smart wallets

El desarrollo de smart wallets genera más tráfico RPC que el desarrollo de EOA porque cada operación de usuario implica simulación, lecturas de nonce y sondeo de recibos. Usa un endpoint con latencia constante y acceso a archivo si necesitas estado histórico. El servicio API de OnFinality proporciona acceso RPC gestionado, y los nodos dedicados están disponibles para equipos que necesitan capacidad aislada.

Para opciones de endpoint específicas de cada cadena, el Asistente RPC cubre recomendaciones concretas. Comienza con la guía de endpoints RPC multicadena y luego reduce a la cadena que estás probando. Si estás comparando proveedores, realiza tus propias mediciones de latencia y tasa de errores en lugar de confiar en afirmaciones de marketing.

• Usa un endpoint gestionado para desarrollo y CI.
• Usa un nodo dedicado cuando necesites rendimiento predecible.
• Mide la tasa de éxito y la latencia p95 por método antes de comprometerte.

Próximos pasos para construir con cuentas inteligentes

Una vez que el diagnóstico pase, pasa a un cliente de bundler como permissionless.js o las utilidades de abstracción de cuentas de viem. Construye una operación de usuario, simúlala con eth_call o el endpoint de simulación del bundler y luego envíala. Mantén el script de diagnóstico en tu repositorio como prueba de humo para nuevos entornos.

Revisa la guía RPC de Gnosis si estás probando en Gnosis Chain, y la guía de endpoints RPC de Arbitrum para despliegues en L2. Para una visión más amplia de la infraestructura, lee la guía de alojamiento de nodos blockchain. Cuando estés listo para seleccionar un endpoint, la página del Asistente RPC sobre el mejor proveedor RPC para proyectos Web3 es un punto de partida práctico.

• Añade el script de diagnóstico a CI.
• Simula antes de enviar.
• Monitorea las tasas de error del bundler y del paymaster.
• Documenta las autoridades de actualización y recuperación.