There is no native mechanism on NEAR to prevent users from sending assets to an address on an incompatible or mismatched network. When a user sends NEAR tokens, NEP-141 assets, or bridged funds while connected to the wrong chain ID or contract namespace, the funds are permanently and irreversibly lost. No on-chain primitive, wallet-layer check, or shared standard currently exists to validate mutual network capability before a transaction is broadcast. This gap affects every dApp, bridge, DEX, and wallet built on NEAR that handles cross-chain or multi-network interactions.

- Ethereum EIP-155 introduced chain ID replay protection in response to significant fund loss events; NEAR has no equivalent cross-chain address scoping standard.

- "Wrong network" sends are among the top-3 reported causes of irreversible fund loss in blockchain support channels across all major ecosystems.

- Current NEAR wallets (MyNearWallet, Meteor, Ledger Live) perform zero recipient network compatibility checks at the transaction signing layer.

- Rainbow Bridge exposes users to wrong-destination errors with no on-chain revert path.

- NEAR Discord and developer forums contain recurring reports of fund loss due to cross-chain address confusion — an ongoing signal of an unmet infrastructure need.

- I am actively building a cross-chain dApp on NEAR and have found no composable safety primitive to build on, requiring a full in-house implementation with no shared audit surface.

I am developing a cross-chain dApp on NEAR and face a forced binary: (a) implement full address validation and network capability logic in-house, without a community-reviewed standard or shared audit, or (b) ship without cross-chain safety and accept the risk of user fund loss. Neither is acceptable for a production product.

This blocks:

- Launching a safe cross-chain transfer product on NEAR

- Implementing user-facing safety guarantees that match what Ethereum and Cosmos ecosystems already offer

- Onboarding non-technical users who cannot be expected to verify chain IDs manually

- Positioning NEAR as a credible destination for bridge partners and institutional integrators who require documented safety standards

Proposed: Cross-Chain Safe Transfer Protocol (CSTP)

1. UserProfile contract — each NEAR account deploys a lightweight contract declaring its supported network capabilities (chain IDs, contract namespaces, bridge endpoints). Queryable by any wallet or dApp.

2. Mutual capability matching — before broadcasting, the initiating wallet or dApp queries both sender and recipient UserProfile contracts and validates that a network intersection exists. If none, the transaction is blocked with a human-readable error before any gas is spent.

3. Staged broadcast window — after capability check passes, a configurable delay window (30s–5min, user-set) allows the sender to cancel before finality. An emergency cancel function is callable within the window.

4. NEP standard — the UserProfile interface and capability-check flow are codified as a NEAR Enhancement Proposal, allowing wallets, bridges, and DEXes to implement one composable standard rather than independent ad-hoc solutions.

Estimated resources: 2 senior Rust/NEAR SDK engineers × 3 months for spec, reference implementation, NEP authoring, and security audit.

Existing reference: Ethereum EIP-155 (chain ID scoping), IBC channel handshake in Cosmos (mutual capability negotiation).

- Pagoda / NEAR Protocol core team: best positioned to shepherd the NEP process and integrate capability checks into official wallet SDKs and NEAR CLI.

- Rainbow Bridge team: direct incentive to reduce cross-chain user error; already operating at the bridge infrastructure layer.

- MyNearWallet and Meteor Wallet teams: natural partners for wallet-level staged broadcast UX implementation.

- Myself (Muhammad, IronClaw Dev): available to contribute to the reference smart contract implementation, TypeScript SDK bindings, and NEP drafting.