EIP-2612 es la extensión Permit de ERC-20: permite que el titular de un token conceda una asignación de gasto mediante una firma off-chain en lugar de una transacción `approve` on-chain, de forma que una llamada `permit()` y la acción siguiente se puedan agrupar en una sola transacción, y el titular no necesita pagar gas por separado para el paso de aprobación.
Características clave
- Aprobaciones sin gas en una sola llamada: El titular firma un mensaje EIP-712 off-chain; una única llamada permit() lo verifica y establece la asignación, evitando una transacción approve on-chain independiente.
- Seguridad y compatibilidad con versiones anteriores: Cada permit consume un nonce único y creciente, y está vinculado al dominio EIP-712 del token (nombre, chain ID, dirección de contrato).
- Integración fluida con DeFi y wallets: Los DEX, protocolos de préstamo y relayers pueden agrupar permit -> acción en una transacción atómica.
Por qué EmpoorioChain no necesita un estándar al estilo de EIP-2612
EIP-2612 existe para resolver dos problemas específicos de Ethereum: una transacción de aprobación on-chain independiente, y que el titular tenga que pagar gas por ella. En EmpoorioChain, los extrínsecos ya se pueden agrupar y patrocinar de forma nativa — una transferencia no requiere un paso previo de aprobación en el caso habitual, y pallet-paymaster permite que un tercero cubra la comisión. No se necesita ningún tipo de permit independiente, dominio EIP-712 ni actualización de contrato para obtener la misma experiencia de usuario; esta surge del propio modelo base de cuentas y comisiones.
Modelo de transferencia de tokens
En Ethereum, mover tokens ERC-20 en nombre de otra persona normalmente requiere `approve` + `transferFrom`. En EmpoorioChain, cada cuenta mantiene su saldo directamente bajo su AccountId32 en pallet-emp-assets; una transferencia directa es un único extrínseco. Cuando el gasto delegado realmente se necesita, el pallet expone su propio extrínseco de tipo aprobación — no un patrón específico reinventado por token.
Modelo de patrocinio de comisiones
El pallet-paymaster de EmpoorioChain permite que un tercero (un servicio de wallet, el backend de una dApp o un relayer) cubra la comisión de transacción del extrínseco firmado de un usuario. Esto ofrece la misma experiencia sin gas que persigue EIP-2612, como una funcionalidad nativa de abstracción de comisiones, en lugar de un esquema de firma permit basado en EIP-712 superpuesto a ERC-20.
Cómo funcionan las transferencias sin gas en EmpoorioChain
A continuación se muestran dos ejemplos mínimos que trasladan los dos escenarios más habituales al estilo de EIP-2612 a las primitivas nativas de EmpoorioChain, usando @polkadot/api contra pallet-emp-assets.
1. El titular paga su propia comisión (autopatrocinado)
El titular firma y paga la comisión él mismo. Un único extrínseco `assets.transfer` mueve el activo — no se necesita ninguna función permit independiente.
// Self-sponsored: the token holder signs and pays their own fee.
// A single extrinsic moves the asset directly — pallet_emp_assets accounts
// are keyed by AccountId32, so there is no separate "associated token
// account" or approve step to bundle in first.
import { ApiPromise, WsProvider, Keyring } from "@polkadot/api";
const api = await ApiPromise.create({
provider: new WsProvider("wss://rpc.testnet.empooriochain.org"),
});
const keyring = new Keyring({ type: "sr25519" });
const owner = keyring.addFromUri("//your-seed-here");
const assetId = 1;
const recipient = "5FHneW...";
const amount = 1_000_000;
const hash = await api.tx.assets
.transfer(assetId, recipient, amount)
.signAndSend(owner);
console.log("Sent (self-sponsored):", hash.toString());2. Un tercero paga la comisión (patrocinado por un relayer)
Aquí el titular firma el extrínseco, pero un relayer o el backend de una dApp cubre la comisión en DMS, mediante el soporte nativo de paymaster de EmpoorioChain.
// Relayer-sponsored: the holder signs a payload off-chain, a relayer
// submits it and pays the fee. EmpoorioChain's fee-abstraction pallets
// (pallet_paymaster / pallet_account_abstraction) support this natively,
// without an EIP-712-style permit type or a separate approval transaction.
import { ApiPromise, WsProvider, Keyring } from "@polkadot/api";
const api = await ApiPromise.create({
provider: new WsProvider("wss://rpc.testnet.empooriochain.org"),
});
const keyring = new Keyring({ type: "sr25519" });
const relayer = keyring.addFromUri("//relayer-seed-here");
const assetId = 1;
const recipient = "5FHneW...";
const amount = 500_000;
// signedPayload is produced client-side by the token holder.
const hash = await api.tx.assets
.transfer(assetId, recipient, amount)
.signAndSend(relayer, { payload: signedPayload });
console.log("Sent (relayer-sponsored):", hash.toString());