{"id":"ERC-4519","name":"NFTs Tied to Physical Assets","status":"Final","chain":"both","category":{"id":"physical","name":"Physical & Real World","description":"Connecting NFTs to physical items"},"journeyStages":[{"id":"specialized","name":"Specialized Interactions","description":"Physical items, AI, social, gaming"}],"uxImpact":"ERC-4519 links an NFT to a physical asset address and defines mutual authentication with the owner or user. It does not require NFC or another particular transport; the implementation chooses the channel, key provisioning, and trust process for physical collectibles, devices, and other assets.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-4519","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-4519","summary":"ERC-4519 links an NFT to a physical asset address and defines mutual authentication with the owner or user. It does not require NFC or another particular transport; the implementation chooses the channel, key provisioning, and trust process for physical collectibles, devices, and other assets.","applicability":{"whenToUse":["Your product addresses: no way to verify if NFT actually represents a physical item.","Your product addresses: counterfeit physical goods sold with fake NFT certificates.","The flow should deliver: authenticate the physical asset through the implementation's channel and show the binding result.","You are designing a physical item verification experience with visible states and recovery paths."],"whenToAvoid":["The physical item has no compatible authentication or key-provisioning system.","The product cannot identify the supported asset, owner, and user roles.","You need a successful challenge alone to prove physical custody or product authenticity."]},"designerTakeaways":["Design the flow to support physical-asset authentication through the implementation's chosen channel.","Design the flow to support a physical asset signing a challenge when the implementation provisions that key path.","Design the flow to support physical asset can query and verify its current NFT owner.","Branch the state UI by optional addressAsset/addressUser: user-only uses notAssigned or userAssigned; asset-only uses waitingForOwner or engagedWithOwner; both use waitingForOwner, engagedWithOwner, waitingForUser, or engagedWithUser."],"problemsSolved":[{"problem":"No way to verify if NFT actually represents a physical item","oldWay":"Trust certificate, seller claims, or central authority","newWay":"Authenticate the physical asset through the implementation's channel and show the resulting NFT binding","impact":"critical"},{"problem":"Counterfeit physical goods sold with fake NFT certificates","oldWay":"Hope the serial number matches, check paper authenticity","newWay":"A provisioned physical asset can sign a challenge; the product must explain the key and provisioning trust","impact":"critical"},{"problem":"Physical asset ownership disconnected from NFT ownership","oldWay":"Transfer NFT separately from physical item, hope they stay together","newWay":"Physical asset can query and verify its current NFT owner","impact":"high"},{"problem":"No standard for physical asset state management","oldWay":"Each project invents custom verification systems","newWay":"Standard states include waitingForOwner, engagedWithOwner, waitingForUser, and engagedWithUser when both asset and user addresses exist","impact":"medium"}],"uxPatterns":[{"name":"Physical Item Authentication","description":"Authenticate the physical item through its configured channel and show ownership context","userFlow":["User opens verification app","App opens the implementation's authentication channel","User completes the physical-asset challenge","Provisioned asset signs the cryptographic challenge","App verifies signature against NFT","Shows authenticity result with details"]},{"name":"Verification Result Display","description":"Show clear authenticity and ownership status","userFlow":["Verification completes successfully","Show prominent verified badge","Display item details from NFT metadata","Show current owner information","Provide link to ownership history"]},{"name":"Ownership Transfer with Physical","description":"Coordinate NFT transfer with physical-asset authentication when the implementation requires it","userFlow":["Seller initiates transfer","Seller completes the implementation's physical-asset authentication","Buyer receives item physically","Buyer completes the implementation's authentication channel to confirm receipt","NFT ownership transfers on-chain","Both parties see confirmation"]},{"name":"Asset State Dashboard","description":"View and manage physical asset engagement states","userFlow":["User views dashboard of physical assets","Each shows current engagement state","Different actions based on state","Can lend to operators","Track items not in possession"]}],"uiComponents":[{"name":"PhysicalVerification","description":"Initiates and manages the implementation's physical-asset authentication channel","states":["ready","scanning","verifying","success","failed","unsupported"],"props":["onVerify","timeout","challengeProvider","channel"]},{"name":"AuthenticityBadge","description":"Show implementation- or externally reported verification status with its source; do not imply the badge proves authenticity on its own.","states":["verified","unverified","suspicious","unknown"],"props":["status","timestamp","verificationDetails"]},{"name":"PhysicalAssetCard","description":"Displays physical asset with state and actions","states":["engaged","waiting","lent","transferring"],"props":["asset","state","operator","onAction"]},{"name":"TransferCeremony","description":"Optional application flow for coordinating physical and NFT transfer checks; ERC-4519 does not define this transfer workflow.","states":["seller-verify","buyer-verify","confirming","complete"],"props":["seller","buyer","asset","onComplete"]}],"antiPatterns":[{"pattern":"Assuming every transfer uses the same physical-authentication channel","why":"The standard does not mandate NFC or a universal transfer ceremony","instead":"Use the implementation's authentication channel and show the exact proof and trust boundary","severity":"critical"},{"pattern":"Not explaining what physical authentication proves","why":"Users may confuse a key challenge with a full authenticity or custody guarantee","instead":"Explain what was authenticated, the channel used, and the key-provisioning trust","severity":"high"},{"pattern":"Hiding engagement state from users","why":"Users confused about who can use the physical item","instead":"Show waitingForOwner, engagedWithOwner, waitingForUser, or engagedWithUser with owner/user/asset context","severity":"high"},{"pattern":"Assuming NFC is the only authentication channel","why":"Valid implementations may use another channel, and an NFC scan alone is not a universal authenticity proof","instead":"Use the implementation's configured channel and explain its key-provisioning trust; add fallbacks only when supported","severity":"medium"},{"pattern":"Requiring verification for every view","why":"Friction for legitimate owners checking their items","instead":"Cache verification with clear \"last verified\" timestamp","severity":"medium"}],"keyTakeaways":["ERC-4519 = cryptographic link between physical items and NFTs","A provisioned physical asset can authenticate through an implementation-defined channel","States: waitingForOwner, engagedWithOwner, waitingForUser, and engagedWithUser when both addresses exist","Always show verification status and engagement state clearly"],"technicalNotes":"ERC-4519 standardizes a physical asset's Ethereum address, owner/user relationships, mutual authentication, and engagement states. It does not require NFC or another transport; the implementation defines the authentication channel, key provisioning, and trust boundary. Use the exact conditional state set waitingForOwner, engagedWithOwner, waitingForUser, and engagedWithUser when both asset and user addresses exist, and explain what a successful challenge establishes before showing authenticity or custody claims.","specConstraints":[{"id":"mutual-authentication","constraint":"Ownership and use transfers are complete only after the specified mutual authentication process with the physical asset.","appliesTo":"application","normativity":"normative","specQuote":"In order to complete the ownership transfer of a token, the new owner must carry out a mutual authentication process with the asset, which is off-chain with the asset and on-chain with the token, by using their Ethereum addresses. Similarly, a new user must carry out a mutual authentication process with the asset to complete a use transfer.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#specification","designImplication":"Show ownership or use transfer as pending until the required asset challenge completes, and distinguish on-chain token transfer from the off-chain authentication that establishes the physical link."},{"id":"owner-only-user-assignment","constraint":"Only the NFT owner can assign a user.","appliesTo":"application","normativity":"normative","specQuote":"Only the owner of the EIP-4519 NFT can assign a user.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#specification","designImplication":"Gate user-assignment controls using the current owner authority and explain when an assignment changes the token's engagement state."},{"id":"timeout-seconds","constraint":"Timeout values are expressed in seconds because the contract uses the current block timestamp as Unix-epoch seconds.","appliesTo":"application","normativity":"rationale","specQuote":"When the asset calls `updateTimestamp`, the smart contract must call `block.timestamp`, which provides current block timestamp as seconds since Unix epoch. For this reason, `timeout` must be provided in seconds.","specSection":"Rationale / Tie Time","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#tie-time","designImplication":"Label timeout inputs and countdowns in seconds or a clearly converted duration, and avoid mixing them with millisecond device timestamps without an explicit conversion."},{"id":"erc721-extension-compat","constraint":"The standard extends EIP-721 and remains compatible with the commonly used metadata and enumerable extensions.","appliesTo":"application","normativity":"rationale","specQuote":"This standard is an extension of EIP-721. It is fully compatible with both of the commonly used optional extensions (`IERC721Metadata` and `IERC721Enumerable`) mentioned in the EIP-721 standard.","specSection":"Rationale / EIP-721-based","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#backwards-compatibility","designImplication":"Retain standard NFT metadata and enumeration behaviors while adding physical-asset identity, user assignment, and authentication status."},{"id":"asset-authenticity-boundary","constraint":"The physical asset should generate a random Ethereum address whose secret is known only to the asset.","appliesTo":"application","normativity":"security-considerations","specQuote":"The physical asset should have the ability to generate an Ethereum address from itself in a totally random way so that only the asset is able to know the secret from which the Ethereum address is generated.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#security-considerations","designImplication":"Separate NFT ownership from physical authenticity in product claims, and disclose the implementation's authentication channel, key provisioning, and trust boundary before showing a genuine-asset result."},{"id":"physical-identity-attribute","constraint":"An ERC-4519 NFT should use at least one of addressAsset or addressUser to identify the physical asset or user.","appliesTo":"application","normativity":"normative","specQuote":"They are optional attributes but at least one of them should be used in an NFT.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#specification","designImplication":"Show which physical-asset or user identity is present, and branch the engagement state from the available attribute instead of presenting an unqualified verified state."},{"id":"shared-secret-verification","constraint":"Assets, owners, and users should verify that they are using the correct shared secret keys.","appliesTo":"application","normativity":"normative","specQuote":"Assets, owners and users should check they are using the correct shared secret keys.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#specification","designImplication":"Give key-mismatch and failed-authentication states their own explanation. Do not label the physical asset genuine when the shared-secret check has not completed."},{"id":"physical-key-provisioning","constraint":"The security rationale recommends manufacturer-controlled token creation and reconstructing asset secrets from non-sensitive helper data when appropriate.","appliesTo":"application","normativity":"security-considerations","specQuote":"In order to ensure this, it is recommended that only the manufacturer of the asset has the ability to create its associated token. In the case of an IoT device, the device firmware will be unable to share and modify the secret. Instead of storing the secrets, it is recommended that assets reconstruct their secrets from non-sensitive information such as the helper data associated with Physical Unclonable Functions (PUFs).","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-4519#security-considerations","designImplication":"Show who provisioned the asset identity and which key-provisioning method the deployment trusts. Do not present one hardware method as required by the standard."}],"lastUpdated":"2026-09-18","sources":[{"label":"ERC-4519 official specification","url":"https://ercs.ethereum.org/ERCS/erc-4519","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-4519","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-4519","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-4519","markdown":"https://www.eipsfordesigners.com/standards/ERC-4519/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-4519/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-4519","official":"https://ercs.ethereum.org/ERCS/erc-4519","discussion":"https://ethereum-magicians.org/search?q=ERC-4519"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}