{"id":"ERC-7943","name":"Universal RWA Interface","status":"Final","chain":"ethereum","category":{"id":"physical","name":"Physical & Real World","description":"Connecting NFTs to physical items"},"journeyStages":[{"id":"asset-display","name":"Asset Discovery & Display","description":"Seeing tokens, NFTs, and balances"},{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"},{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.","slug":"erc-7943","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7943","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7943","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7943","type":"discussion"},{"label":"CMTA CMTAT-ACE implementation","url":"https://github.com/CMTA/CMTAT-ACE","type":"implementation"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","hasDetailedContent":true,"content":{"id":"ERC-7943","specConstraints":[{"id":"frozen-transfer-amount","constraint":"A transfer must not exceed the account’s unfrozen amount.","appliesTo":"application","normativity":"normative","specQuote":"- MUST validate that the `amount` being transferred doesn't exceed the unfrozen amount (which is the difference between the current balance and the frozen balance).","specSection":"Specification — canSend, canReceive, canTransfer, and getFrozenTokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens","designImplication":"Show available and frozen balances separately and prevent a send amount that exceeds the unfrozen amount."},{"id":"permissioned-transfer-result","constraint":"A permissioned transfer check returns false when a rule, pause, or privileged restriction would prevent the transfer.","appliesTo":"application","normativity":"normative","specQuote":"- MUST return false if any permissioned rule would prevent a given transfer from succeeding. A transfer refers to any operation that emits the token's canonical transfer event. A permissioned check can be a pausing mechanism, a call to `canSend`/`canReceive`, or anything else that requires privileged actors.","specSection":"Specification — canSend, canReceive, canTransfer, and getFrozenTokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens","designImplication":"Treat a negative permission check as a visible transfer-ineligible state. Do not reduce it to a generic insufficient-balance error."},{"id":"privileged-force-actions","constraint":"Forced transfer and freeze actions must be access-restricted because unauthorized access could steal assets.","appliesTo":"application","normativity":"security-considerations","specQuote":"- **Access Control for `forcedTransfer` and `setFrozenTokens`**: The security of the mechanism chosen by the implementer to restrict access to these functions is paramount. Unauthorized access could lead to asset theft. Secure patterns (multisig, timelocks) are highly recommended.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#security-considerations","designImplication":"Identify privileged actors and disclose when an asset can be frozen or moved by a compliance authority rather than by the holder."},{"id":"freeze-beyond-current-balance","constraint":"The freeze operation may cover more assets than the account currently holds to withhold future balances.","appliesTo":"application","normativity":"normative","specQuote":"- MUST allow freezing more assets than those held. This allows for future balances withholding.","specSection":"Specification — setFrozenTokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#setfrozentokens","designImplication":"Show the frozen amount even when it exceeds the current balance and explain that future receipts may also be unavailable."},{"id":"public-transfer-eligibility","constraint":"Public transfers and permissionless minting must respect the relevant send, receive, and transfer permission checks.","appliesTo":"application","normativity":"normative","specQuote":"- **Public transfers** (`transfer`, `transferFrom`, `safeTransferFrom`, etc.) MUST NOT succeed in cases where `canTransfer` would return `false`, or where `canSend` would return `false` for the `from` address, or `canReceive` would return `false` for the `to` address.","specSection":"Specification — Additional Specifications","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications","designImplication":"Keep transfer, receive, mint, and burn failure states distinct so users can see which permission blocked the action."},{"id":"permissionless-burn-limit","constraint":"Permissionless burns cannot exceed the unfrozen amount, while privileged burns must update the frozen status when they do.","appliesTo":"application","normativity":"normative","specQuote":"- **Burning** in permissionless contexts (e.g., public `burn` functions) MUST respect the `canTransfer` check, MUST respect the `canSend` check on the token holder, and MUST NOT allow burning more assets than the unfrozen amount. In permissioned contexts (e.g., authorized burning by privileged roles), burning MAY succeed for accounts where `canSend` on the token holder would return `false`, and MAY burn more assets than the unfrozen amount, in which case the contract MUST update the frozen status accordingly and emit a `Frozen` event before the underlying base token transfer event.","specSection":"Specification — Additional Specifications","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications","designImplication":"Show the remaining unfrozen amount and disclose when a privileged burn changes the frozen status."},{"id":"base-token-integration","constraint":"Existing wallets and explorers can use base-token functionality, but full ERC-7943 support requires explicit integration.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThis EIP defines a new interface standard and does not alter existing ones like [ERC-20](./eip-20.md), [ERC-721](./eip-721.md), and [ERC-1155](./eip-1155.md). Standard wallets and explorers can interact with the base token functionality of implementing contracts, subject to the rules enforced by that contract's implementation of `canSend`, `canReceive`, `canTransfer`, and `getFrozenTokens` functions. Full support for the [ERC-7943](./eip-7943.md) functions requires explicit integration.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#backwards-compatibility","designImplication":"Keep ordinary token views available while labeling frozen and permissioned behavior that a generic wallet cannot infer."},{"id":"forced-action-security","constraint":"Forced transfer and freeze functions are susceptible to front-running; access-control choices are paramount, secure patterns are highly recommended, and implementations must follow general smart contract security practices.","appliesTo":"application","normativity":"security-considerations","specQuote":"- **Access Control for `forcedTransfer` and `setFrozenTokens`**: The security of the mechanism chosen by the implementer to restrict access to these functions is paramount. Unauthorized access could lead to asset theft. Secure patterns (multisig, timelocks) are highly recommended.\n- **Front-running of the `forcedTransfer` and `setFrozenTokens` functions**: Both functions are susceptible to front-running, similar to the `approve` function of [ERC-20](./eip-20.md). Furthermore, if the suggestion to allow freezing more than what an account owns is not followed, any account may be incentivized to front-run attempts to freeze its balance when receiving new funds. Additional features to gradually increment or decrement the frozen status MAY be considered for implementation.\n- **Standard Contract Security**: Implementations MUST adhere to general smart contract security best practices (reentrancy guards where applicable, checks-effects-interactions, etc.). Specifically, in the checks-effects-interactions consideration, implementations need to be aware of tokens having hooks, especially on recipients as in [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md). In such circumstances, it might be convenient to adopt reentrancy guards to prevent unwanted executions.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#security-considerations","designImplication":"Show a clear pending and completed state for privileged actions and avoid presenting them as ordinary holder transfers."},{"id":"token-hook-reentrancy","constraint":"Implementations must follow general smart contract security practices, account for recipient hooks, and consider reentrancy guards where applicable.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"- **Standard Contract Security**: Implementations MUST adhere to general smart contract security best practices (reentrancy guards where applicable, checks-effects-interactions, etc.). Specifically, in the checks-effects-interactions consideration, implementations need to be aware of tokens having hooks, especially on recipients as in [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md). In such circumstances, it might be convenient to adopt reentrancy guards to prevent unwanted executions.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#security-considerations","designImplication":"No additional user control is required by this clause, but integrations should not assume a recipient callback is side-effect free."},{"id":"eligibility-context","constraint":"Eligibility functions MAY depend on on-chain context such as timestamp, block number, or msg.sender.","appliesTo":"application","normativity":"normative","specQuote":"- MAY depend on on-chain state such as current timestamp, block number, or `msg.sender`.","specSection":"Specification > canSend, canReceive, canTransfer, and getFrozenTokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens","designImplication":"Label eligibility as context-dependent and refresh it at action time; a previously allowed state may change with block or caller context."},{"id":"frozen-query-semantics","constraint":"getFrozenTokens MAY exceed an account's current balance, and an ERC-721 query MAY return true even when the account does not hold the token.","appliesTo":"application","normativity":"normative","specQuote":"- `getFrozenTokens` will return the absolute frozen amount, which MAY exceed the account's current balance. In [ERC-721](./eip-721.md) tokens, it MAY return true even if the account does not hold the token.","specSection":"Specification > canSend, canReceive, canTransfer, and getFrozenTokens","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#cansend-canreceive-cantransfer-and-getfrozentokens","designImplication":"Show frozen amount and current balance as separate values, including future-withholding or tokenId-not-held states."},{"id":"forced-transfer-safeguards","constraint":"forcedTransfer MAY bypass canTransfer; when it does, counted frozen assets MUST be unfrozen before the base transfer, and a Frozen event MUST be emitted.","appliesTo":"application","normativity":"normative","specQuote":"- It MAY bypass the `canTransfer` checks. If this happens, and the transfer involves tokens that are currently counted as frozen, it MUST unfreeze the assets first and emit a `Frozen` event before the underlying base token transfer event reflecting the change. Having the unfrozen amount changed before the actual transfer is critical for tokens that might be susceptible to reentrancy attacks doing external checks on recipients, as is the case for [ERC-721](./eip-721.md) and [ERC-1155](./eip-1155.md) tokens.","specSection":"Specification > forcedTransfer","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#forcedtransfer","designImplication":"Privileged-transfer review should disclose the bypass, the unfrozen amount change, and the resulting compliance status."},{"id":"error-specificity","constraint":"Standard eligibility errors MAY be used as general reverts, MAY be replaced by more specific errors, or MAY be omitted.","appliesTo":"application","normativity":"normative","specQuote":"The `ERC7943CannotSend`/`ERC7943CannotReceive`/`ERC7943CannotTransfer` errors MAY be used as a general revert mechanism whenever internal calls to `canSend`/`canReceive`/`canTransfer` return false. They MAY be replaced by more specific errors depending on the custom checks performed inside those calls, or simply not used.","specSection":"Specification > Additional Specifications","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications","designImplication":"Render the actual blocked reason from the implementation and avoid promising a particular selector or error label across all tokens."},{"id":"error-specificity-recommended","constraint":"Specific errors SHOULD be thrown when applicable, including a distinct insufficient-unfrozen-balance condition.","appliesTo":"application","normativity":"normative","specQuote":"In general, the standard prioritizes error specificity, meaning that specific errors such as `ERC7943InsufficientUnfrozenBalance` SHOULD be thrown when applicable. The `ERC7943InsufficientUnfrozenBalance` error SHOULD be triggered when a transfer is attempted from `account` with an `amount` less than or equal to its balance, but greater than its unfrozen balance, or with a `tokenId` which is currently frozen. If the `amount` is greater than the whole balance or the `tokenId` is not owned by the `account`, unrelated to the frozen amount, more specific errors from the base standard SHOULD be used instead.","specSection":"Specification > Additional Specifications","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#additional-specifications","designImplication":"Map specific errors to actionable copy such as frozen amount, insufficient unfrozen balance, or token ownership rather than a generic transfer failure."},{"id":"eligibility-separation","constraint":"The standard separates account-level eligibility from transfer-level authorization and evaluates them independently.","appliesTo":"application","normativity":"rationale","specQuote":"- **Separation of concerns**: The standard separates account-level eligibility (`canSend`, `canReceive`) from transfer-level authorization (`canTransfer`). `canSend` and `canReceive` evaluate whether an account is eligible to participate independently of any specific transfer parameters such as counterparty, amount, or token identifier. `canTransfer` evaluates whether a specific transfer is permissible under permissioned compliance rules, taking into account frozen balances, transfer limits, counterparty restrictions, and account eligibility. This separation provides clear semantics for integrators and avoids confusion between account eligibility and transfer-specific validation. It also enables one-way restrictions where an account may be blocked from receiving but still allowed to send, which is common in regulated environments.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-7943#rationale","designImplication":"Keep account eligibility, counterparty, amount, tokenId, and transfer-policy checks visible as distinct reasons in a blocked or allowed state."}],"sources":[{"label":"ERC-7943 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7943","type":"official-spec"},{"label":"CMTA CMTAT-ACE implementation","url":"https://github.com/CMTA/CMTAT-ACE","type":"implementation"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.","partialDeployment":{"body":"The official specification includes educational reference implementations, and CMTA's public CMTAT-ACE project documents tested ERC-7943 support in a compliance-token integration. That evidence supports implementation-specific design guidance, not broad wallet or token adoption. Full uRWA support requires explicit integration and access-control review."},"designerTakeaways":["Show transferable balance and frozen balance separately, then explain why the current amount may be unavailable to send.","Call canSend, canReceive, and canTransfer before presenting a transfer as available, and retain a specific blocked state when policy changes.","Treat forcedTransfer and setFrozenTokens as privileged compliance actions; show the actual authority and evidence supplied by the implementation."],"applicability":{"whenToUse":["A regulated token or RWA product has a verified ERC-7943 implementation and a documented compliance policy.","Wallets, marketplaces, or DeFi integrations need to explain why a transfer is allowed, blocked, frozen, or enforced.","The product can identify the base token type, interface ID, policy source, and privileged authority."],"whenToAvoid":["The token only implements ERC-20, ERC-721, or ERC-1155 without a verified uRWA interface.","The product cannot disclose the implementation's policy, freeze authority, or enforcement controls.","A generic token screen would imply KYC, legal ownership, or compliance merely from an interface ID."]},"prototypeFirst":[{"screen":"Restricted-token transfer review","why":"A familiar transfer form must communicate that eligibility and frozen balance can change the result.","covers":["Allowed transfer","Sender blocked","Recipient blocked","Frozen amount exceeds available"],"include":["Base token type","Transferable and frozen balances","canTransfer result","Policy source","Retry after refresh"]},{"screen":"Enforcement and freeze activity","why":"A privileged action changes asset mobility and may carry legal or operational consequences.","covers":["Freeze set","Freeze lifted","Forced transfer","Unauthorized action"],"include":["Authority identity","Amount or token ID","Event and transaction links","Policy evidence","Audit trail"]}],"mentalModel":[{"label":"Base token","description":"ERC-7943 extends a base token such as ERC-20, ERC-721, ERC-1155, or ERC-6909; base ownership and balance semantics still apply."},{"label":"Eligibility check","description":"canSend, canReceive, and canTransfer expose the implementation's current policy decision without changing state."},{"label":"Frozen amount","description":"getFrozenTokens reports an absolute frozen amount, which can exceed the current balance and can make future receipts unavailable."},{"label":"Enforcement authority","description":"forcedTransfer and setFrozenTokens require restricted access chosen by the implementation; the interface does not identify the legal or governance authority."},{"label":"Policy change","description":"A transfer can become unavailable when policy or freeze state changes, so a prior quote or check is not a permanent authorization."}],"statesToDesign":[{"state":"uRWA interface detected","trigger":"ERC-165 reports a supported ERC-7943 interface for the base token type.","userNeed":"Know why this token has additional transfer states.","designResponse":"Show base token type, supported uRWA checks, policy source, and a restricted-asset notice without inventing legal claims."},{"state":"Transfer allowed","trigger":"canSend, canReceive, and canTransfer return true and base token checks pass.","userNeed":"Know the transfer is eligible at the time of review.","designResponse":"Show transferable balance, policy timestamp, and the possibility that state may change before execution."},{"state":"Transfer blocked","trigger":"An eligibility check returns false or the base token rejects the operation.","userNeed":"Understand which side or constraint prevented the transfer.","designResponse":"Show sender, recipient, amount/token ID, check result, and implementation-provided reason or support path."},{"state":"Partially frozen","trigger":"Frozen amount is below the current balance.","userNeed":"Know how much can still move.","designResponse":"Show total, frozen, and current transferable amounts with an explicit refresh point."},{"state":"Fully or over-frozen","trigger":"Frozen amount meets or exceeds current balance, or a token ID is frozen.","userNeed":"Know why a transfer or burn is unavailable.","designResponse":"Block the action and explain that future receipts may also be constrained until the freeze state changes."},{"state":"Privileged enforcement","trigger":"An authorized caller invokes forcedTransfer or setFrozenTokens.","userNeed":"Understand the exceptional asset movement and its authority.","designResponse":"Show the actor, target, amount/token ID, policy evidence, event, transaction, and whether frozen balance was changed."}],"designDecisions":[{"question":"What does a blocked transfer reason say?","recommendation":"Use the implementation's specific error or policy result, then offer an issuer/support path; do not invent a KYC or legal reason.","rationale":"ERC-7943 defines decision surfaces, not a universal reason taxonomy or legal status."},{"question":"How should balances be displayed?","recommendation":"Show total, frozen, and transferable balance as separate values with a timestamp.","rationale":"The interface allows frozen amounts above current balance, so total balance alone is misleading."},{"question":"How should enforcement appear in history?","recommendation":"Use a distinct enforcement event style and identify the privileged actor and policy source.","rationale":"A forced transfer is not equivalent to a holder-initiated transfer and may bypass ordinary checks in some implementations."}],"problemsSolved":[{"problem":"A standard transfer form cannot explain compliance restrictions","oldWay":"Show the total balance and let the transaction fail with a generic revert.","newWay":"Query sender, recipient, transfer, and frozen-state checks before signing.","impact":"critical"},{"problem":"Users cannot tell how much of an asset is movable","oldWay":"Assume current balance equals transferable balance.","newWay":"Show total, frozen, and transferable amounts or token IDs.","impact":"high"},{"problem":"Enforcement movements look like ordinary transfers","oldWay":"Render forcedTransfer in the same activity row as a holder-signed transfer.","newWay":"Show exceptional authority, policy evidence, and the forced-transfer event separately.","impact":"high"}],"uxPatterns":[{"name":"Policy-Aware Transfer","description":"Preflight the actual token's uRWA checks and show why an amount is transferable or blocked.","components":["Total/frozen/transferable balance","Eligibility result","Policy source","Refresh action"],"userFlow":["Detect base and ERC-7943 interface support","Load frozen state and policy checks","Enter recipient and amount/token ID","Call canSend, canReceive, and canTransfer","Show allowed or blocked review","Recheck before submission"]},{"name":"Enforcement Activity Record","description":"Give freeze and forced-transfer events a distinct, auditable presentation.","components":["Authority badge","Frozen-state delta","Forced-transfer label","Policy/evidence links"],"userFlow":["Receive an event or transaction","Identify actor and target","Read amount/token ID and freeze delta","Open policy or issuer evidence","Update balances and transfer availability"]}],"uiComponents":[{"name":"TransferabilityBreakdown","description":"Separates base balance or ownership from frozen and currently transferable amounts.","kind":"list","states":["loading","transferable","partially-frozen","fully-frozen","policy-blocked","unsupported"],"props":["tokenType","account","tokenId","balance","frozenAmount","canSend","canReceive","canTransfer"]},{"name":"EnforcementEventRow","description":"Marks freeze and forced-transfer actions with actor, target, evidence, and state changes.","kind":"status","states":["frozen","unfrozen","forced-transfer","unknown-authority","pending"],"props":["eventType","actor","account","amount","tokenId","transactionHash","policySource"]}],"antiPatterns":[{"pattern":"Treating ERC-7943 as proof an asset is legally compliant","why":"The interface exposes controls and checks but does not establish legal status, identity, or jurisdiction.","instead":"Show the actual policy, issuer evidence, and contract authority separately.","severity":"critical"},{"pattern":"Showing total balance as transferable","why":"Frozen amounts can be unavailable or exceed the current balance.","instead":"Display total, frozen, and current transferable values.","severity":"critical"},{"pattern":"Assuming all ERC-7943 interfaces exist on every base token type","why":"The standard has separate fungible, non-fungible, and multi-token interfaces and implementations may support one or more.","instead":"Use ERC-165 detection and render only the supported interface.","severity":"high"},{"pattern":"Calling a forced transfer a user transfer","why":"Forced transfers use privileged access and can have different compliance semantics.","instead":"Give enforcement a distinct activity and authority presentation.","severity":"high"},{"pattern":"Caching eligibility as permanent","why":"Policy, freeze, and recipient state can change between preflight and execution.","instead":"Refresh before submission and retain a pending/rejected recovery state.","severity":"medium"}],"vocabulary":[{"use":"Transferable amount","avoid":"Available balance","why":"The remaining balance may still be locked by a policy or base-token rule."},{"use":"Frozen by this token policy","avoid":"Account banned","why":"A frozen amount or transfer check does not by itself identify a person's legal status."},{"use":"Forced transfer","avoid":"Recovery transfer","why":"The standard does not define why enforcement happened or guarantee that the recipient is a recovery address."}],"technicalNotes":"ERC-7943 defines ERC-20, ERC-721, and ERC-1155 interfaces (and a multi-token variant) with canSend, canReceive, canTransfer, getFrozenTokens, forcedTransfer, and setFrozenTokens surfaces. Implementations must advertise the appropriate ERC-165 interface ID and enforce transfer restrictions through the base token operations. Frozen amounts are absolute and may exceed current balances. forcedTransfer and setFrozenTokens must be access-controlled, but the standard does not mandate an authority model, legal reason, policy registry, or specific error taxonomy. Full uRWA support requires explicit integration.","relatedStandards":[{"id":"ERC-20","relationship":"Fungible base token that can be extended by the ERC-7943 fungible interface."},{"id":"ERC-721","relationship":"Non-fungible base token that can expose per-token frozen and eligibility state."},{"id":"ERC-1155","relationship":"Multi-token base interface supported by the ERC-7943 multi-token variant."},{"id":"ERC-3643","relationship":"A broader permissioned-token implementation reference whose policy and identity model must remain distinct from ERC-7943."}],"keyTakeaways":["ERC-7943 standardizes compliance checks and enforcement surfaces, not legal meaning or wallet support.","Show total, frozen, and transferable values separately.","Feature-detect the supported base-token interface and recheck policy before execution.","Give privileged freeze and forced-transfer actions a distinct audited presentation."]},"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7943","markdown":"https://www.eipsfordesigners.com/standards/ERC-7943/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7943/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7943","official":"https://ercs.ethereum.org/ERCS/erc-7943","discussion":"https://ethereum-magicians.org/search?q=ERC-7943"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}