Permit
EIP-2612 gasless approvals for DALPAsset tokens. Holders sign approval messages off-chain, while a relayer submits the permit on-chain without changing transfer compliance.
A DALPAsset holder can approve a spender by signing an EIP-2612 message instead of sending a separate approve() transaction. A relayer or application submits the signature on-chain. The token writes the ERC-20 allowance only after the signature matches the holder and the submitted nonce, deadline, and EIP-712 domain are valid.
Permit changes the approval step, not the transfer rules. The feature does not move tokens, bypass compliance modules, or add governance settings. Any later transferFrom still runs through the token's normal transfer checks.
Related architecture pages: token features catalog and asset contracts.
Where permit fits
Use this feature for allowance-based integrations when a holder needs to approve a spender without paying gas for a separate approval transaction.
A typical flow is:
- The application reads feature metadata and the holder's current nonce.
- The holder signs an EIP-712 message that names the owner, spender, value, nonce, deadline, chain, and verifying contract.
- A relayer submits the signed message through the API or directly on-chain.
- The token verifies the signature and deadline, consumes the nonce, and writes the allowance.
- A later
transferFromuses that allowance and still goes through the token's normal transfer checks.
This makes the feature useful for dapp and API flows that want to combine approval with a later transaction. Permit is not a transfer mechanism.
What permit validates
A submitted permit must match the holder's signed message. The validation covers:
| Check | Why it matters |
|---|---|
| Owner signature | Proves the holder approved the spender and value. |
| Nonce | Prevents the same signature from being accepted more than once. |
| Deadline | Rejects signatures after the holder-approved expiry. |
| EIP-712 domain | Binds the signature to the permit feature contract and chain. |
| Spender and value | Ensures the submitted allowance matches what the holder signed. |
If any check fails, the submission reverts and the allowance is unchanged, so callers can treat a failed permit as having no approval side effect.
Operational boundaries
The feature keeps the approval experience lighter, but the surrounding controls stay the same:
- A successful submission emits the standard ERC-20
Approval(owner, spender, value)event. - EIP-2612 does not emit a separate permit-specific event.
- The feature has no governance or custodian configuration.
- The feature does not run token hooks.
- Transfer compliance still applies when a spender later attempts to move tokens.
- Integrations must show the holder the spender, value, deadline, chain, and token before asking for a signature.
Because a signed message can authorize spending, wallet and application UX should make the approval details clear before the holder signs.
Failure modes and edge cases
| Condition | Result |
|---|---|
| Expired deadline | The transaction reverts with no allowance change. |
| Nonce mismatch | The transaction reverts because the signature is no longer current. |
| Wrong chain or token | Domain verification fails. |
| Reused signature | Nonce replay protection rejects the second submission. |
| Later transfer blocked | The allowance can exist, but transferFrom can still fail if token transfer checks reject the movement. |
If a holder signs more than one message for the same nonce, only one can succeed. After the token consumes that nonce, older signatures for it are invalid.
Replay-history projection
DALP maintains a replay-history projection for direct EIP-2612 permit() transactions that the indexer can identify from the transaction selector.
The projection records the owner, token, transaction hash, block number, block time, and a per-owner display counter. Treat replay history as a forensic view for analysis, not as the source of truth for the live allowance.
Approvals routed through account-abstraction or wallet execution paths may not appear in replay history. In those paths, the outer transaction selector is not the EIP-2612 permit selector. Use the live allowance view when the product needs current approval state. Use replay history when an operator needs to inspect direct submissions that the indexer can identify.
Integration guidance
For user-facing permit flows:
- Read the holder's current nonce and the token's EIP-712 domain data.
- Build the message from the exact owner, spender, value, nonce, deadline, chain, and verifying contract.
- Ask the holder to sign only after displaying the spender, value, token, chain, and expiry.
- Submit the signature before the deadline.
- Treat the returned allowance and any replay-history rows as separate views: allowance is live state; replay history is audit context.
For API usage, see Token permit API.
See also
- Token permit API - read permit metadata and relay signed approvals
- Token Features Catalog - return to the full feature catalog
- Asset Contracts - deployment architecture and role model
- Compliance Modules - transfer enforcement after an allowance exists
Historical Balances
Timestamp-based balance and total supply checkpoints for point-in-time token queries. Passive feature with no roles or economic rewrite. Required by Fixed Treasury Yield.
Maturity Redemption
How DALP handles bond maturity redemption: operator maturity actions, treasury funding and allowance readiness, indexed solvency signals, and holder redemption after maturity.