ERC-5643, also known as Token State, is an Ethereum Request for Comment (ERC) that defines a standard interface for non-fungible tokens (NFTs) to manage time-based, recurring state changes. At its core, it enables a token's properties or access rights to expire and automatically renew based on a predefined subscription period, such as monthly or annually. This is implemented through a mandatory expiresAt function that returns a UNIX timestamp for when the current state ends, and an renewSubscription function to extend it. The standard is minimal and opinionated, focusing solely on the state management logic and leaving payment mechanics and tokenomics to the implementing contract.
ERC-5643
What is ERC-5643?
ERC-5643 is an Ethereum token standard that introduces a mechanism for automatic, recurring subscription payments directly on the blockchain.
The primary innovation of ERC-5643 is moving subscription logic on-chain and making it a native property of the token itself. Unlike traditional SaaS models where subscription status is stored in a centralized database, here the state is verifiable and enforceable by the smart contract. This enables new use cases for NFTs, transforming them from static digital collectibles into dynamic membership passes, software licenses, or content access keys that require active renewal. For example, a streaming service could issue an NFT that grants access only while the subscription is paid up, with the NFT effectively becoming inactive—or "soulbound"—if the subscription lapses.
Implementing ERC-5643 requires careful design of the renewal mechanism. The standard does not specify how payment is collected; the renewSubscription function could transfer ERC-20 tokens, native ETH, or even trigger a cross-chain action. This flexibility allows developers to build complex subscription economies. A key technical consideration is managing the state expiration. Contracts must handle queries for expired tokens and may implement hooks to notify other systems or alter metadata when a subscription renews or lapses, enabling dynamic visual changes in associated artwork or attributes.
The standard promotes interoperability by providing a common interface that wallets, marketplaces, and explorers can universally understand. A decentralized application (dApp) can trustlessly check the expiresAt value of any ERC-5643-compliant NFT to determine if a user's access is valid. This solves a significant problem in Web3 where subscription status is often managed off-chain, breaking composability. By standardizing this pattern, ERC-5643 paves the way for a new class of recurring revenue models and utility-based NFTs that are integral to the growing decentralized physical infrastructure (DePIN) and service networks.
Etymology & Origin
The naming and development history of the ERC-5643 standard, which introduced a mechanism for expirable token ownership.
ERC-5643 is an Ethereum Improvement Proposal (EIP) that defines a standard interface for Non-Fungible Tokens (NFTs) with expirable ownership, commonly referred to as subscription NFTs. The term's origin is purely functional: 'ERC' denotes an Ethereum Request for Comments, a standard format for proposing application-level conventions, while '5643' is its unique, sequential identifier assigned within the EIP repository. This naming follows the established pattern for all ERC standards, such as ERC-20 and ERC-721, which are defined by their proposal number.
The proposal was authored by William Schwab, Lucas Henne, and Michael Elliot, and was formally entered into the EIP process as Draft status in March 2023. Its creation was driven by the need to formalize a pattern for NFTs that encode a temporal access right, moving beyond the perpetual ownership model of standard NFTs. The core concept—stateful expiration—was designed to enable use cases like software licenses, media subscriptions, and time-bound memberships directly on-chain, providing a native mechanism for access to lapse without manual revocation.
The technical nomenclature within the standard is precise. The key function expiresAt(uint256 tokenId) returns a Unix timestamp for when the token's ownership expires, anchoring the mechanism in a globally consistent time standard. The proposal builds upon the foundational ERC-721 metadata and enumeration extensions, ensuring compatibility with existing NFT infrastructure. By standardizing this pattern, ERC-5643 provides a common language and predictable behavior for developers building subscription-based economies, allowing wallets and marketplaces to uniformly display and interact with time-bound tokens.
Key Features
ERC-5643, also known as the Stateful Subscription Token Standard, defines a mechanism for recurring payments and time-based access on the Ethereum blockchain.
Stateful Expiration
The core innovation of ERC-5643 is the expiresAt function, which returns a timestamp for when a token's validity ends. This creates a stateful subscription model, where a token's utility can be programmatically revoked after a period, unlike standard NFTs which are permanent. Smart contracts can check this state to grant or deny access to a service.
Automatic Renewal & Top-ups
The standard enables automated subscription management. Wallets or dedicated managers can call the renewSubscription function, which:
- Extends the
expiresAttimestamp for a token. - Typically requires a payment in the network's native currency or a specified ERC-20 token.
- Allows for flexible billing cycles (monthly, yearly) enforced on-chain.
Backward Compatibility
ERC-5643 is designed as a minimal extension of ERC-721 (NFTs). This means:
- Any existing NFT contract can integrate the standard by adding its functions.
- It remains fully compatible with all NFT marketplaces, wallets, and infrastructure that support ERC-721.
- The subscription logic is an optional add-on, preserving the core NFT properties.
Cancellation & Refunds
The standard includes a cancelSubscription function for terminating a recurring payment. Implementations can define their own policies for:
- Prorated refunds: Returning a portion of the payment for the unused period.
- Grace periods: Allowing access for a short time after non-payment.
- This provides a clear, on-chain framework for ending subscriptions, enhancing user trust.
Use Cases & Applications
ERC-5643 tokenizes access rights for:
- SaaS & Content: Pay-for-access software, newsletters, or premium articles.
- Gaming: Monthly battle passes or seasonal content packs.
- Memberships: DAO memberships, club access, or subscription-based NFTs.
- Real-World Services: Tokenized gym memberships or cloud storage with automated billing.
Technical Implementation
Developers implement a few key functions:
expiresAt(uint256 tokenId) → uint64: Returns the token's expiry timestamp.renewSubscription(uint256 tokenId, uint64 duration): Called with payment to extend validity.- Events like
SubscriptionUpdateare emitted for state changes. - The token manager (often the contract itself) controls renewal logic and payments.
How It Works: The Subscription Mechanism
An explanation of the technical architecture and operational flow of the ERC-5643 token standard, which enables recurring payments and access control for NFTs.
ERC-5643, also known as Tokenized Subscriptions, is an Ethereum token standard that introduces a stateful subscription mechanism directly into non-fungible tokens (NFTs). It extends the widely adopted ERC-721 and ERC-1155 standards by adding a core function, expiresAt(uint256 tokenId), which returns a UNIX timestamp for when the token's subscription period ends. This function allows smart contracts and user interfaces to programmatically check a token's active status, enabling automated access control and recurring billing logic without requiring manual renewal checks or off-chain validation.
The core subscription logic is managed through two primary functions: renewSubscription and cancelSubscription. When a user calls renewSubscription, they must send the required payment (often in a native token like ETH or an ERC-20) to extend the token's expiry timestamp. This payment is typically routed to a predefined beneficiary address, such as the original creator or a DAO treasury. Conversely, cancelSubscription stops the automatic renewal process for a token, though the access granted by the token remains valid until its current expiry time. This design cleanly separates the financial transaction from the access state.
A key innovation of ERC-5643 is its minimal and permissionless design. The standard does not enforce how payments are made or who can renew a subscription; it only provides the interface to update the expiry state. This allows for immense flexibility in implementation. For example, a project could build a subscription NFT that renews monthly with ETH, annually with a stablecoin, or even via a custom token-gated system. The state change—the updated expiresAt timestamp—is the single source of truth for an application to grant or deny access to a service, content, or physical good.
From a developer's perspective, integrating ERC-5643 involves listening for the SubscriptionUpdate event, which is emitted whenever a token's expiry changes. Front-end applications can use this event to update user interfaces in real-time, showing subscription status or prompting for renewal. Smart contracts that provide gated services would query the expiresAt function in their own logic, often within a modifier like onlyValidSubscription(tokenId), to restrict function calls to only holders with active tokens. This creates a robust, on-chain system for managing recurring relationships.
Practical use cases for this mechanism are extensive. They include software-as-a-service (SaaS) licenses, premium content platforms, membership DAOs, time-limited in-game items, and physical asset rentals. For instance, a music streaming dApp could mint an NFT that serves as a monthly pass; the user's access to high-fidelity streams is automatically revoked the moment block.timestamp exceeds the token's stored expiry, unless a renewal transaction is submitted. This transforms static NFTs into dynamic, utility-bearing assets with enforceable, time-based economics directly embedded in the token's state.
Core Interface Example
An overview of the technical interface and core functions defined by the ERC-5643 standard for managing subscription-based NFTs.
The ERC-5643 standard, also known as Token State or Subscription NFT, defines a minimal smart contract interface that enables a non-fungible token (NFT) to have an expiration date and a renewal mechanism. This interface introduces the expiresAt(uint256 tokenId) function, which returns a Unix timestamp indicating when the token's current state or subscription period ends. A return value of 0 signifies the token is in a permanent, non-expiring state. This core function allows wallets, marketplaces, and other smart contracts to programmatically check a token's active status, enabling new utility models beyond static ownership.
The standard's primary innovation is its statefulness over time, transforming an NFT from a static record of ownership into a dynamic asset with a lifecycle. This is achieved without mandating a specific renewal logic, granting developers flexibility. Common implementations might tie renewal to a payment, a governance vote, or the completion of a task. The interface is intentionally minimal, comprising only the state query function (expiresAt) and a required StateUpdate event that must be emitted whenever a token's expiration timestamp changes. This design ensures broad compatibility and easy integration with existing ERC-721 and ERC-1155 NFT infrastructures.
Practical applications for ERC-5643 are extensive, particularly in software licensing, subscription-based content, and membership programs. For instance, a software company could issue an NFT that grants access to a premium application, where the expiresAt value dictates the subscription's end date. A decentralized autonomous organization (DAO) might use it for time-bound voting rights or committee memberships. The standard also facilitates automated expiration handling, where external systems can listen for the StateUpdate event to trigger actions like revoking access or displaying a renewal prompt, creating a more seamless user experience.
From a technical perspective, implementing ERC-5643 requires careful consideration of access control and state management. The contract must define who is authorized to update a token's expiration—typically the token owner or a designated admin contract. Developers must also decide whether expiration leads to the token being burned, rendered inert, or placed into a locked state. It's crucial that the StateUpdate event is emitted for all state changes, including renewals and cancellations, to maintain a reliable public record. This event-driven architecture is key for building responsive off-chain indexers and user interfaces.
The ERC-5643 standard represents a significant step toward more complex and useful on-chain relationships. By adding a simple temporal dimension to NFT ownership, it unlocks models for recurring revenue, temporary access, and phased benefits. Its lightweight design ensures it can be composed with other standards, such as ERC-2981 for royalties or ERC-5192 for soulbound tokens, to create sophisticated digital asset ecosystems. As the blockchain space evolves, interfaces like ERC-5643 provide the foundational primitives for building the next generation of dynamic, utility-driven applications.
Use Cases & Examples
ERC-5643, the Subscription NFT standard, enables recurring payments and time-based access for on-chain assets. Its primary applications revolve around managing active/inactive states for digital memberships, software licenses, and content access.
Ecosystem & Adoption
ERC-5643, also known as the Subscription NFT Standard, is an Ethereum token standard that enables recurring, time-based payments for NFTs. It defines a mechanism for managing subscription states and renewal periods directly on-chain.
Core Mechanism: State Management
The standard introduces a state function that returns a uint64 representing the expiration timestamp of the subscription. A value of 0 indicates the subscription is canceled, while any future timestamp indicates it is active until that point. This on-chain state is the single source of truth for access control.
Renewal & Payment Hook
ERC-5643 defines a renewSubscription function that accepts a tokenId and a duration. When called, it triggers a required payment, typically in a native or ERC-20 token. The standard is payment-agnostic, meaning the specific payment logic and amount are implemented in the overriding contract, allowing for flexible monetization models.
Use Cases & Applications
This standard enables new business models for NFT-based services:
- Software-as-a-Service (SaaS): Granting periodic access to software or APIs.
- Premium Content: Subscribing to media, newsletters, or exclusive creator content.
- Gaming: Time-limited access to premium features, maps, or items.
- Membership Clubs: Managing dues for decentralized autonomous organizations (DAOs) or physical clubs.
Technical Implementation
To create an ERC-5643 NFT, a developer extends the standard interface (IERC-5643). Key implementation decisions include:
- Defining the payment token and price calculation logic in
renewSubscription. - Integrating access control checks using the
statefunction. - Optionally emitting the standard
SubscriptionUpdateevent for off-chain indexing. It is often paired with ERC-721 for the underlying NFT.
Comparison to ERC-20 Subscriptions
Unlike recurring approvals for ERC-20 tokens (which can be risky), ERC-5643 offers key advantages:
- User Control: The subscription is tied to a specific NFT
tokenIdthe user owns and can cancel by setting state to0. - Granularity: Each NFT can have its own independent subscription period.
- Composability: As an NFT, it can be integrated with wallets, marketplaces, and other DeFi protocols that support the ERC-721 standard.
Security & Design Considerations
ERC-5643 defines a standard interface for subscription-based NFTs, enabling automatic, periodic state changes. This introduces unique security and design patterns for managing recurring payments and access control.
State Expiry & Renewal Logic
The core mechanism is the expiresAt timestamp. When a subscription expires, the contract's state must be updated. This can be done via:
- Automatic on-chain renewal: A
renewSubscriptionfunction that transfers tokens and updates the timestamp. - Off-chain renewal proofs: A
setExpirationfunction callable by an authorized renewer address, requiring secure off-chain payment rails. - Manual owner renewal: The NFT owner calls
renewSubscriptionafter making an external payment. The choice impacts user experience and decentralization.
Renewer Role & Centralization
The optional renewer address is a privileged role with permission to call setExpiration. This creates a trust assumption and centralization point.
- Security Risk: A compromised or malicious renewer can arbitrarily expire or extend subscriptions.
- Design Mitigation: Implement multi-signature controls or a DAO for the renewer role. Alternatively, use a fully on-chain, automated renewal model to eliminate this role entirely, though this may increase gas costs.
Front-Running & Payment Attacks
On-chain renewal functions are vulnerable to transaction ordering dependency.
- Scenario: A user submits a
renewSubscriptionTX. A front-runner could see this and immediately purchase the NFT (if transferable) to steal the paid-for renewal. - Mitigations:
- Make the NFT non-transferable (
soulbound) while active. - Use a commit-reveal scheme for renewals.
- Implement a direct
renewSubscriptionForfunction where payment is made on behalf of the current token owner.
- Make the NFT non-transferable (
Integration with Payment Standards
ERC-5643 subscriptions must integrate with token transfer standards for payment. Key considerations:
- ERC-20 Approval Race: Ensure the contract handles the ERC-20 approval/transferFrom flow securely, checking allowances before state changes.
- Gas Efficiency: Bundling renewal with other actions (like ERC-4907 rental extension) can improve UX.
- Native Currency: While the standard uses
IERC20, extending support for native ETH/MTIC requires careful design to prevent reentrancy and useaddress(0)checks.
State Consistency & View Functions
Contracts must maintain consistency between the expiresAt state and the isRenewable flag.
isRenewableshould returnfalseif the subscription is expired and the NFT is non-transferable, preventing renewal for a lapsed asset.- Off-chain Indexing: The
SubscriptionUpdateevent is critical for indexers and front-ends to track expiration changes. Incomplete event emission will break external services. - Time Manipulation: Logic should rely on
block.timestamp, but be aware of minor miner manipulation; avoid critical logic on sub-1-hour precision.
Example: Magazine NFT Subscription
A concrete implementation example:
- Token ID 123: Represents a monthly digital magazine.
- State:
expiresAt = 1698768000(Nov 1, 2023). - Renewal Cost: 10 USDC per month.
- Flow:
- On Oct 25, owner calls
renewSubscription(123, 1). - Contract transfers 10 USDC from owner.
expiresAtupdates to1701446400(Dec 1, 2023).- A
SubscriptionUpdateevent is emitted.
- On Oct 25, owner calls
- Security: The NFT is made non-transferable (
soulbound) to prevent the front-running attack described earlier.
Comparison: ERC-5643 vs. Related Standards
A feature comparison of ERC-5643's subscription model against other token standards for managing state changes.
| Feature / Attribute | ERC-5643 (Subscription NFT) | ERC-20 | ERC-721 | ERC-1155 |
|---|---|---|---|---|
Primary Purpose | Time-based state expiration & renewal | Fungible tokens | Non-fungible tokens (NFTs) | Multi-token (Fungible & Non-Fungible) |
State Expiration | ||||
Automatic State Renewal | ||||
On-Chain Subscription Logic | ||||
Token Identifier | uint256 tokenId | N/A (balance-based) | uint256 tokenId | uint256 id |
State Data Storage | Per-token expiration timestamp | Per-account balance | Per-token metadata URI | Per-id & per-account balance |
Inherent Transfer Logic | Yes (inherits ERC-721) | Yes | Yes | Yes |
Typical Gas Cost for State Update | ~45k-60k gas (renewal) | N/A | N/A (static) | N/A (static) |
Common Misconceptions
ERC-5643, or Stateful NFTs, introduces a subscription model to the NFT standard. This section clarifies frequent misunderstandings about its mechanics, security, and use cases.
No, ERC-5643 is not a standalone NFT standard but a state extension that can be added to existing NFTs like ERC-721 or ERC-1155. It defines a minimal interface for managing a subscription expiration time (expires) for a specific token ID. The core NFT contract remains unchanged for ownership and transfers, while the subscription state is managed separately, often through a dedicated manager contract. This design allows developers to add time-based functionality to their existing NFT collections without needing to migrate assets to a new contract.
Frequently Asked Questions (FAQ)
ERC-5643, also known as the Subscription NFT Standard, introduces a mechanism for tokenizing recurring payments and access rights on-chain. This FAQ addresses common technical and practical questions about its implementation and use cases.
ERC-5643 is an Ethereum token standard that defines a minimal interface for managing tokenized subscriptions, where an NFT's state represents an active or expired membership. It works by adding a getState function that returns a uint256 representing the subscription's expiration timestamp and a renewSubscription function that allows the token owner or an approved operator to pay to extend this expiration. The core mechanism uses the NFT itself as the access key, with its state checked on-chain to grant or deny services, eliminating the need for off-chain billing systems.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.