By Eco research. Updated Apr 2026.
​

ERC-7628 is an extension to the ERC-721 standard that adds quantifiable, transferable ownership shares to non-fungible tokens. Proposed by Chen Liaoyuan in February 2024, it lets a single NFT carry a divisible share balance while preserving the token's uniqueness, enabling dividend distribution, collateralization, and profit-sharing without wrapping the NFT into a separate ERC-20 contract.
​

ERC-7628 is an ERC-721 extension that attaches a decimal-precision share ledger to each NFT. Authored by Chen Liaoyuan (@chenly, kip.pro) and submitted as a draft in February 2024, it introduces eight new functions alongside the standard ERC-721 interface, filling the design gap between ERC-721 (unique tokens, no fractions) and ERC-1155 (fractions, but no per-token identity). ERC-7628 preserves both properties.
​

The problem ERC-7628 addresses is structural. Before the standard, developers who needed fractional ownership of a specific NFT chose between two imperfect paths: lock the NFT in a vault contract and issue separate ERC-20 tokens representing shares, or use ERC-1155 and sacrifice the one-to-one identity guarantee that makes an ERC-721 token meaningful as a unique record. The vault-plus-ERC-20 pattern adds two contracts, a lock-and-unlock step, and a liquidity risk when the vault has a small holder count. ERC-1155 forces the asset into a semi-fungible paradigm that does not map cleanly onto real-world instruments like real estate titles or music copyrights that must exist as singular, identifiable records.
​

ERC-7628 solves the problem at the token layer itself by embedding the share accounting directly inside the ERC-721 contract. No vault is required. The NFT remains active in marketplaces, lending protocols, and governance systems while its shares circulate independently. The official EIP-7628 specification on the Ethereum Improvement Proposals site defines the full interface, events, and security requirements.
​

ERC-7628 adds a share accounting layer to each token ID inside an ERC-721 contract. Shares are integers scaled by a decimal factor from shareDecimals(), and each token ID's balance is tracked separately via shareOf(tokenId). Approval and transfer mechanics mirror ERC-20 but operate on token IDs, not wallet addresses. The contract owner controls supply issuance; all other transfers require owner or approved-spender authorization.
​

The eight core functions divide cleanly into three groups. Four read-only view functions expose the state: shareDecimals() returns the decimal precision, totalShares() returns aggregate shares across all tokens, shareOf(tokenId) returns a specific token's balance, and shareAllowance(tokenId, spender) returns the current approved ceiling for any spender on that token ID.
​

Three state-modifying functions handle authorization and movement. approveShare(tokenId, spender, shares) authorizes a spender to move up to a set number of shares on behalf of the token's owner. transferShares(fromTokenId, toTokenId, shares) moves shares between two token IDs within the contract. transferSharesToAddress(fromTokenId, to, shares) moves shares to a wallet address, minting a new ERC-721 token for the recipient if one does not already exist in the contract. The eighth function, addSharesToToken(tokenId, shares), is restricted to the contract owner and increases the share supply for a specific token.
​

Two events track state changes. SharesTransfered emits on any share movement, indexed on both the source and destination token IDs to allow efficient off-chain filtering. SharesApproved emits whenever an allowance is set or updated. Both events carry the full context needed to reconstruct a complete share history for any NFT using a single indexed query, without requiring off-chain snapshot tooling or Merkle proofs.
​

The specification requires ERC-721 backward compatibility in full. A compliant ERC-7628 contract reports all existing ERC-721 interface IDs and adds the new ERC-7628 interface ID. Wallets and marketplaces unaware of ERC-7628 interact with the token as a standard ERC-721. One critical security requirement: any ERC-721 ownership transfer via the standard transferFrom must clear all share approvals on the source token, preventing stale delegations from carrying over to the new owner.
​

The eight mandatory functions cover all four categories needed for a complete share accounting system: read-only state queries, supply issuance, authorization, and share movement. Every ERC-7628 implementation must expose all eight, though the optional decimal precision allows issuers to choose between whole-unit shares for governance and high-decimal fractions for fine-grained economic splits.
​

The four view functions are gas-free when called off-chain via eth_call. Any distribution contract can read shareOf(tokenId) for a set of token IDs and compute proportional payouts entirely onchain without relying on centralized snapshots. This is the core composability property that makes ERC-7628 useful for royalty splitting and RWA income distribution: the share balance lives in the token contract and is always current, always readable.
​

The addSharesToToken restriction to contract owner is an intentional centralization trade-off. Token issuers retain board-level control over share supply, similar to how a company's articles of incorporation reserve new share issuances to the board. This works for institutional issuers with clear governance structures. Protocols that require immutable share supplies can disable the function at deploy time or gate it behind a governance contract with a timelock, which is the recommended approach for decentralized organizations that want to prevent dilution without issuer consent.
​

ERC-7628 targets four primary scenarios: profit-sharing for creator royalties, fractional ownership of unique physical or digital assets, DeFi collateralization of revenue-bearing NFTs, and investment stake management inside DAO portfolios. Each use case requires a token that is simultaneously unique as an identifiable record and divisible as an economic claim.
​

An artist or music label minting a collection can assign shares to each token at mint time. When the collection earns secondary royalties under ERC-2981, a distribution contract reads shareOf(tokenId) across all tokens in a wallet and distributes proportional payouts without a separate ERC-20 contract or off-chain Merkle tree. Because the share balance is always current in the token contract, distributions can run fully onchain on any schedule. Generative art collections with thousands of tokens benefit most: a single totalShares() read plus per-token shareOf queries give a complete payout table.
​

Tokenized real estate, infrastructure, and commodity protocols issue a single ERC-721 token per asset, preserving the one-to-one mapping with the physical legal instrument. ERC-7628 shares represent fractional economic interests in that asset's income stream. This avoids the vault-plus-ERC-20 pattern that requires holders to unwrap ERC-20 tokens back to the ERC-721 before exercising any governance or physical claim right. The rwa.xyz dashboard tracked over $19B in onchain real-world asset value as of Q1 2026. That volume creates real demand for ownership-fraction mechanics that preserve the unique legal identity of each underlying asset.
​

Lending protocols that accept revenue-bearing NFTs as collateral can use shareOf(tokenId) to price a borrower's economic claim continuously, rather than relying on a stale floor-price oracle. When a borrower defaults, the protocol calls transferShares to assign the revenue interest to itself without moving the NFT, keeping the token's onchain provenance record intact and avoiding secondary-market sale mechanics. This two-layer separation of token identity from economic interest is what makes ERC-7628 substantially cleaner than the vault pattern for collateral use cases: the collateral event does not require a custody transfer.
​

DAOs and investment collectives that hold portfolios of unique assets (music rights, domain names, patent licenses) can manage equity-like stakes inside a single ERC-721 contract without a separate ERC-20 governance token. Members receive initial shares via addSharesToToken, transfer partial stakes via transferShares without triggering any NFT sale event, and approve delegates through approveShare. The standard's shareDecimals() flexibility lets issuers design whole-unit stakes for vote-counting governance and high-decimal fractional stakes for fine-grained income distribution, within the same contract.
​

ERC-7628 is one of four approaches to NFT fractionalization, each suited to a different set of requirements. The table below covers token structure, liquidity, gas model, and whether the underlying NFT's uniqueness survives fractionalization. Choosing the right approach depends on whether open-market liquidity or collateral composability is the primary goal.
​

The vault-plus-ERC-20 pattern, used by protocols such as Fractional.art (later rebranded Tessera), produces the most liquid fractional shares because ERC-20 tokens trade on Uniswap, Curve, and any compatible AMM. The NFT is locked and the vault becomes a single point of failure for the asset, but for highly liquid blue-chip NFTs where market price discovery matters more than DeFi composability, this trade-off can be worth making. ERC-7628 makes the opposite trade: it keeps the NFT active in lending, governance, and transfer flows, while accepting that shares are not natively AMM-listed.
​

ERC-1155 handles multiple token amounts per ID efficiently, but loses the categorical distinction that makes an ERC-721 token meaningful as a unique record. Real estate titles, patent filings, and domain ownership certificates must be distinguishable individual instruments. ERC-1155 treats IDs as semi-fungible at the platform level; ERC-7628 treats the NFT as categorically unique and layers the economic fraction on top of that uniqueness, not alongside it.
​

The external registry approach, used by some early fractional real estate platforms, keeps the NFT entirely unchanged and stores fractional ownership in a separate contract mapping. This preserves both uniqueness and ERC-721 compatibility but adds a cross-contract read on every query, introduces a registry ownership risk, and creates a coordination requirement between the NFT contract owner and the registry admin. ERC-7628 collapses this into one contract with no external dependency.
​

ERC-7628 introduces three specific risk categories beyond standard ERC-721 security: reentrancy in share transfer functions, stale approval exploitation across ownership changes, and share supply inflation through the owner-controlled addSharesToToken function. Each requires deliberate mitigation in any production implementation.
​

Reentrancy risk arises when a share recipient is a contract that re-enters the transfer function before balance updates complete. The checks-effects-interactions pattern is the standard mitigation: read the current balance, check authorization, decrement the source balance in storage, then perform any external interaction. The OpenZeppelin ReentrancyGuard module provides a ready-made mutex guard. The ERC-7628 draft does not mandate a specific pattern but implicitly requires that all balance mutations be complete before any callback or external call that could trigger re-entry.
​

Stale approval exploitation is addressed by the specification's explicit requirement to clear share approvals on ERC-721 ownership transfer. An implementation that omits this clearing step leaves the new token owner's share balance exposed to transfer by the previous owner's approved spenders. This is analogous to the ERC-20 vulnerability where setting a non-zero allowance over an existing non-zero allowance can be exploited; the ERC-7628 spec treats approval clearing as a security requirement, not a style preference.
​

Share supply inflation through addSharesToToken is a governance risk unique to ERC-7628. Because only the contract owner can call this function, a token buyer must evaluate the issuer's governance structure before acquiring shares. Protocols that want immutable share supplies should override addSharesToToken to revert unconditionally at deploy time, or route it through a DAO governance contract with a minimum 48-hour timelock. The specification permits both patterns; it only requires that the function exist in the interface, not that it always succeed.
​

Implementors must also validate token ID existence before executing any share operation. Calls to shareOf, transferShares, or approveShare against a non-existent or burned token ID should revert cleanly. Failure to enforce this can produce state corruption in contracts that burn ERC-721 tokens mid-operation and leave orphaned share balances in storage that can never be redeemed or transferred.
​

ERC-7628 belongs to a family of ERC-721 extension proposals from 2022 to 2024 that add financial primitives directly to NFTs without requiring a separate token contract. Related standards include ERC-4907 (rentable NFTs, adds a time-bounded user role), ERC-5006 (usage rights with fixed expiry), ERC-3525 (semi-fungible tokens with value slots), and ERC-2981 (royalty standard). ERC-7628 is the narrowest of these: it targets only the share-accounting problem and deliberately avoids expanding into rental, usage, or royalty calculation mechanics.
​

That narrowness is its value. ERC-7628 is composable with ERC-2981: the royalty payout calculated by ERC-2981 can be split across holders using ERC-7628 share data. It is composable with ERC-4907: an NFT can have a renter (ERC-4907) and multiple share holders (ERC-7628) simultaneously without conflict. Each extension touches a different mapping in the contract and emits different events, allowing protocols to implement any combination without interface collisions.
​

For stablecoin and cross-chain settlement, ERC-7628 matters as onchain real-world asset tokenization scales. An RWA token with ERC-7628 shares can serve as collateral in a lending protocol on one chain, distribute income to holders on a second chain, and undergo governance votes on a third, provided the bridging layer preserves the share balance state. Eco Routes handles stablecoin settlement across more than 15 EVM-compatible chains, which increasingly include networks where ERC-721-based RWA protocols are deploying. The share-transfer semantics in ERC-7628 become a relevant integration surface when cross-chain stablecoin flows correspond to economic claims on uniquely identified assets.
​

ERC-20 fractionalization locks the NFT in a vault and issues a separate fungible token. ERC-7628 attaches the share ledger inside the ERC-721 contract itself, so the NFT stays active and retains its full ownership history. No vault, no unlock step, and the share balance is always queryable onchain from the token contract directly.
​

Not natively. ERC-7628 shares are not ERC-20 tokens, so they cannot be listed on Uniswap or Curve directly. For liquid secondary markets, a wrapper contract can bridge shares to ERC-20, accepting the same vault-lock trade-off. ERC-7628 is optimized for structured distribution and DeFi collateralization, not open-market price discovery.
​

Yes. The specification requires full ERC-721 backward compatibility. An ERC-7628 contract passes all standard ERC-721 interface checks via ERC-165 and simply adds the ERC-7628 interface ID. Wallets and marketplaces that do not recognize ERC-7628 interact with the token as a standard ERC-721 without any change to behavior.
​

Only the contract owner can call addSharesToToken, the sole function that increases share supply. This is analogous to a board vote for new equity issuance. Buyers should review whether the issuer has placed this function behind a timelock or governance module before acquiring shares, to assess dilution risk.
​

ERC-7628 does not change the royalty calculation defined by ERC-2981. It provides the share-balance data that lets a distribution contract split royalty proceeds proportionally across holders. ERC-7628 supplies the per-token share values; a separate payout contract uses those values to compute each holder's cut. The two standards are complementary, not overlapping.
​

Sources and methodology. EIP specification sourced from eips.ethereum.org/EIPS/eip-7628 (created February 20, 2024, author Chen Liaoyuan). RWA onchain asset value from rwa.xyz as of Q1 2026. ERC-7628 interface functions verified against the primary EIP text. All cross-standard comparisons (ERC-1155, ERC-4907, ERC-2981) based on their respective EIP specifications.
​

Eco Routes processes stablecoin transfers across EVM chains where ERC-721-based RWA protocols are active. As share-bearing NFTs become collateral in onchain lending protocols, settlement infrastructure that handles underlying stablecoin flows across chains becomes relevant to anyone working with ERC-7628-compliant assets at scale.
​