Permit

Purpose: Permit adds EIP-2612 gasless approvals to DALPAsset. Token holders sign an approval message off-chain using their wallet. Any relayer or authorized party can submit the signature on-chain to set a spending allowance without the holder sending a transaction.

• Doc type: Reference
• What you'll find here: Business impact, risks, controls, failure modes, auditability, dependencies, and ordering notes
• Related:
  • Token Features Catalog
  • Asset Contracts

---

Interface (capabilities)

This feature exposes the following capabilities. It implements EIP-2612 gasless approvals — a pure UX utility with no hooks, no lifecycle integration, and no governance configuration.

---

Business impact

• Holders: Can approve spending without paying gas. Enables single-transaction "approve-and-transfer" flows where the dApp submits the permit and transfer in one transaction.
• Issuer / platform: Improves onboarding UX for integrations requiring allowances (e.g., DeFi protocols, capability contracts). No economic impact.
• Economics: No token movement. Pure UX utility feature.

---

Risks & abuse cases

• Phishing: Users who sign permit messages without checking the spender, amount, deadline, and chain ID can inadvertently authorize malicious spenders. Wallet UX must clearly display permit details.
• Signature replay across chains: Permit signatures are domain-separated (chain ID + contract address). A signature from one chain cannot be replayed on another, but users should be aware that signing is irreversible until the deadline expires.
• Expired permits: Permit signatures include a deadline. Submitting after the deadline reverts. Callers must check deadline before submission.

---

Controls & guardrails

Permit has no on-chain configuration. Nonce-based replay protection is automatic — each signature can only be submitted once.

---

Failure modes & edge cases

• Deadline expired: Submitting a valid signature after the deadline reverts with no effect.
• Nonce mismatch: If the holder submits any transaction that changes their nonce (including another permit), all outstanding permits for older nonces become invalid.
• Wrong chain ID: Signatures from another chain (or testnet) will fail domain verification.

---

Auditability & operational signals

• Approval(owner, spender, value) — standard ERC-20 event emitted when permit is submitted successfully. Indistinguishable from a regular approval in event logs.
• No permit-specific event in base EIP-2612. Submitter address is in transaction calldata, not event logs.

---

Dependencies

• No external dependencies.
• No other features required.
• No hooks — completely independent of the feature hook execution chain.

---

Compatibility & ordering notes

• No hooks — does not interact with onMinted, onBurned, onTransferred, or onRedeemed.
• Order in the feature array is irrelevant.
• Compatible with all other features. Low-risk utility.
• Compatible with compliance modules — permit sets an allowance; the subsequent transfer still goes through compliance checks.

---

Change impact

• Enable after launch: Immediately enables gasless approvals. No retroactive effect.
• Disable: Outstanding signed-but-not-submitted permits are no longer valid. Any integration relying on permit-based flows must fall back to standard approve().
• No configuration to change.

---

See also

• Token Features Catalog — return to the full feature catalog
• Asset Contracts — deployment architecture and role model
• Compliance Modules — transfer enforcement (runs after permit sets allowance)