NEAR Access Key Proliferation & Account Security Risks

introduction

ACCOUNT SECURITY MODEL

The Double-Edged Sword of Flexible Access Keys

NEAR's access key model enables powerful UX patterns but introduces systemic account security risks that wallet developers and security auditors must actively manage.

NEAR Protocol's account model decouples cryptographic keys from account identity, allowing each account to hold multiple access keys with distinct permissions. This design enables user-friendly patterns like limited-use keys for dApp interactions, gasless meta-transactions, and key rotation without changing the human-readable account ID. However, the flexibility that makes these patterns possible also creates a persistent security surface: users can be socially engineered into granting FullAccess keys to malicious contracts, and the long-lived nature of unrevoked keys means a compromise may remain exploitable indefinitely.

The core risk vector lies in the permission model itself. A FullAccess key can sign any transaction for an account, including transferring all assets, deleting the account, or deploying a new contract. Limited-access keys, while restricted by an allowance, a receiver contract, and a method name, are only as safe as the contract they target. A malicious dApp that tricks a user into adding a FullAccess key—often through a confusing wallet prompt—gains persistent, irrevocable control until the key is explicitly deleted. Unlike EVM chains where a single compromised transaction is typically a one-time loss, a compromised access key on NEAR is a backdoor that remains open.

Operationally, the risk compounds over time. Users who interact with many dApps may accumulate dozens of access keys, most of which are never reviewed or revoked. Wallet interfaces that do not surface key management prominently leave users blind to their own exposure. For institutional custodians and exchanges integrating NEAR, the access key model demands a fundamentally different security posture than single-key chains: key lifecycle management, periodic revocation audits, and strict UI/UX controls over what a dApp can request are not optional features but core security requirements. Teams building on NEAR should treat access key hygiene as a first-class operational concern, and Chainscore Labs provides review and integration planning to ensure that key management architecture does not become the weakest link.

ACCOUNT SECURITY EXPOSURE ASSESSMENT

Access Key Risk Snapshot

Evaluates the systemic risks introduced by NEAR's flexible access key model, including full-access key proliferation, limited key permission ambiguity, and long-term key hygiene failures.

Risk Area	Failure Mode	Affected Actors	Severity	Mitigation Priority
Full-Access Key Phishing	Malicious dApp requests a full-access key via wallet prompt; user approves, granting complete account control and fund drainage.	Wallet users, Wallet developers (HERE, Meteor, Nightly), DeFi protocols	Critical	Wallets must enforce human-readable, high-friction warnings distinguishing full-access from limited-access key requests. Auditors should review wallet prompt UX.
Limited Key Permission Ambiguity	User grants a limited-access key with excessive allowances (e.g., unlimited allowance for a specific contract) due to unclear permission scoping, leading to asset loss if the contract is exploited.	dApp developers, Wallet users, Smart contract auditors	High	Standardize permission-scoping UI in wallets. Audit dApp contracts that request broad allowances. Implement allowance revocation tools.
Unrevoked Key Exploitation	User interacts with a dApp, grants a key, and stops using the service. The dApp or a compromised server later exploits the still-valid key to drain assets.	Wallet users, dApp operators, Custodians	High	Wallets must provide a prominent dashboard for viewing and revoking all active access keys. Periodic key rotation should be a recommended security practice.
Compromised dApp Server Key Theft	A dApp's backend database storing user access keys is breached. Attackers use the keys to drain user accounts.	dApp developers, Wallet users, Security auditors	Critical	dApps must never store user keys server-side. Use ephemeral session keys or meta-transactions. Security audits must verify key storage architecture.
Chain Abstraction Key Amplification	A single NEAR full-access key controls assets and contracts on multiple foreign chains via Chain Signatures. Compromise leads to catastrophic cross-chain loss.	Chain abstraction users, MPC network operators, Bridge operators, Custodians	Critical	Implement multi-factor signing policies for cross-chain transactions. Limit the blast radius of a single key. Audit MPC key derivation and signing logic.
Meta-Transaction Relayer Collusion	A relayer authorized via a limited key colludes with a block producer to front-run or censor user meta-transactions.	dApp developers, Relayer operators, MEV researchers	Medium	Design relayer networks with reputation and slashing. Monitor for transaction ordering manipulation. Use commit-reveal schemes for sensitive operations.
Account Recovery Key Mismanagement	User loses their full-access key and has no recovery method set up (e.g., no seed phrase backup, no multi-sig recovery), resulting in permanent loss of all assets.	Wallet users, Wallet developers, Custodians	High	Wallets must enforce recovery setup during onboarding. Support social recovery or multi-sig account models. Audit recovery flow completeness.
Contract Key Delegation Risk	A smart contract is granted a full-access key for automated operations. A vulnerability in the contract logic leads to key compromise and fund drainage.	Smart contract developers, Protocol architects, Auditors	Critical	Avoid granting full-access keys to smart contracts. Use limited keys scoped to specific function calls. Formal verification of contract key usage is essential.

technical-context

ACCOUNT SECURITY MODEL

How NEAR Access Keys Work

NEAR's access key model decouples account authorization from a single keypair, enabling flexible permissioning but introducing a distinct set of security and management risks.

NEAR Protocol replaces the traditional single-keypair account model with a multi-key system where each account can hold multiple access keys, each with its own permissions. Every key is either a full-access key (capable of signing any transaction, including transferring all assets, deleting the account, or deploying contracts) or a function-call access key (limited to calling a specific set of smart contract methods, often with an attached allowance for gas or token spending). This design is the foundation for NEAR's user experience, enabling features like gasless meta-transactions and the ability for a user to grant a dApp limited, revocable permissions without exposing their primary key.

The operational risk emerges from the proliferation of these keys. A common onboarding flow prompts users to generate a full-access key and store it in a wallet, but a malicious or compromised dApp can also request a full-access key, gaining permanent and total control over the account. Even with legitimate function-call keys, users often accumulate a long list of unrevoked permissions for dApps they no longer use. Each unrevoked key represents a persistent attack surface; if the dApp's relayer infrastructure is compromised, an attacker could use a forgotten function-call key to drain the approved allowance or manipulate any contract method within its scope. The viewAccessKeyList RPC method allows anyone to enumerate all active keys for an account, making it trivial for an attacker to audit a target's exposed permissions.

For wallet developers and security auditors, the critical challenge is building interfaces that make key management legible to users. A user should be able to see a clear, real-time inventory of all active keys, their permissions, and the specific contracts they can call, with one-click revocation. Integration teams must also verify that their dApp's requested permissions follow the principle of least privilege, requesting only the specific method_names and allowance required. Chainscore Labs reviews access key management implementations to identify over-privileged key requests, insecure key storage patterns, and gaps in revocation workflows that leave user accounts exposed to long-term compromise.

ACCESS KEY RISK EXPOSURE

Who Is Affected

Wallet Developers

Wallet teams bear the primary responsibility for translating NEAR's access key model into safe user interfaces. The risk of a dApp requesting a full-access key under the guise of a limited-access key is a UI/UX failure that wallets must prevent.

Action items:

Implement clear, non-dismissable warnings when a dApp requests a full-access key.
Default to limited-access keys with explicit user opt-in for full-access.
Build key management dashboards that surface all active keys, their permissions, and a one-click revocation flow.
Audit the AddKey action flow to ensure the permission scope is displayed in human-readable terms, not raw JSON.

Chainscore Labs can review wallet key management flows and permission UX to reduce user-facing attack surfaces.

implementation-impact

ACCESS KEY THREAT MODEL

Attack Vectors and Exploit Patterns

A breakdown of the primary attack vectors that arise from NEAR's flexible access key model, detailing how malicious actors exploit user confusion and permissionless key creation to compromise accounts.

Malicious dApp Full-Access Key Requests

The most critical vector: a malicious or compromised dApp requests a full-access key during a standard wallet connection flow. Users, accustomed to approving transactions, may blindly authorize the request. This grants the attacker complete control over the account, enabling them to drain all assets, rotate keys to lock out the original owner, and delete the account. Wallet developers must implement crystal-clear, unskippable warnings that explicitly differentiate a full-access key request from a limited-access transaction approval.

Unrevoked Legacy Key Exploitation

Users frequently grant limited-access keys to dApps for convenience and then abandon them. These keys, while limited, often retain allowances for high-value fungible token transfers or critical contract calls. An attacker who compromises a dApp's backend or frontend can exploit this pool of unrevoked keys to drain assets from users who have not actively managed their key store. Regular key rotation and revocation hygiene must become a standard user practice, supported by wallet interfaces that surface active key permissions.

Phishing for Seed Phrases via Key Injection

A sophisticated phishing attack involves tricking a user into adding a malicious full-access key to their own account, which the attacker has pre-generated. The attacker then instructs the user to 'verify' their account by sharing the seed phrase of this newly added key, falsely claiming it is a security step. Since the key is on the account, the user may comply, directly handing over full control. This bypasses traditional seed-phrase phishing by exploiting the account model's multi-key architecture.

Limited-Key Scope Creep and Allowance Abuse

A dApp may request a limited-access key with a generous default allowance (e.g., 1000 USDC) for a legitimate function like gasless trading. If the dApp is later compromised or turns malicious, it can drain up to that allowance from every user who granted the key, potentially in a single mass-exploit transaction. The attack surface is defined by the cumulative allowance across all users. Auditors must scrutinize the necessity and size of allowances, and wallets should enforce user-defined spending limits.

Function Call Key to `delete_account`

A limited-access key scoped to a specific contract can be weaponized if that contract has a function that delegates to a dangerous action, such as delete_account on the user's behalf. An attacker who compromises the contract can invoke this function using the user's key, permanently destroying the account and sending remaining funds to a beneficiary address. This highlights the transitive trust problem: a key's security is only as strong as the contract it is authorized to call.

Lack of Time-Bound Key Expiry

NEAR access keys do not have a native expiry date. A key granted for a short-term interaction remains valid indefinitely unless manually revoked. This creates a long-tail risk where a key granted years ago to a now-defunct or compromised service can be used in an attack. The absence of temporal constraints shifts the entire burden of key lifecycle management to the user, a model that consistently fails at scale. Wallet and SDK developers should implement off-chain expiry logic and proactive revocation reminders.

SECURITY AND OPERATIONAL EXPOSURE ASSESSMENT

Risk Matrix for Access Key Management

Evaluates the failure modes, affected actors, and required actions arising from NEAR's flexible access key model, including full-access key compromise, limited-access key misuse, and long-term unrevoked key risks.

Risk Area	Failure Mode	Affected Actors	Severity	Mitigation and Action
Full-Access Key Phishing	Malicious dApp requests a full-access key under the guise of a limited-access key, leading to complete account takeover and asset drain.	Wallet developers, end users, DeFi protocols	Critical	Wallets must enforce clear, non-spoofable UI differentiation between key types. Protocols should never request full-access keys for routine interactions. Audit wallet integration flows.
Limited-Access Key Misconfiguration	A limited-access key is granted excessive allowances (e.g., high allowance for `ft_transfer` on a specific contract), enabling a compromised dApp to drain a specific asset.	dApp developers, end users, DeFi protocols	High	dApps must request the minimum necessary permissions. Wallets should decode and display the exact permissions in human-readable form before user approval. Regularly audit dApp key requests.
Unrevoked Key Exploitation	A user revokes a dApp's front-end access but the on-chain access key remains active. A later compromise of the dApp's backend or a malicious insider uses the still-valid key to act on the user's behalf.	End users, dApp operators, wallet developers	High	Wallets must provide a prominent, easy-to-use interface for viewing and deleting all active access keys. dApp operators should implement off-chain key revocation tracking and encourage users to revoke on-chain.
Function Call Key Allowance Exhaustion	A limited-access key with a specific allowance is used by a relayer or dApp in a way that exhausts the allowance through unexpected transaction ordering or a bug, locking the user out of intended actions.	dApp developers, relayers, end users	Medium	dApps and relayers must model worst-case allowance consumption. Implement monitoring for keys nearing exhaustion. Users should be able to top up allowances without creating a new key.
Seed Phrase vs. Access Key Confusion	A user mistakenly shares their seed phrase or a full-access private key, believing they are only granting limited dApp access, due to poor wallet UX.	Wallet developers, end users	Critical	Wallets must never expose raw private keys in dApp interaction flows. Seed phrases must be handled in a completely separate, secure context. User education on the distinction is mandatory.
Compromised Relayer Key Replay	A relayer's full-access key for a user's account is compromised. The attacker can replay meta-transactions or drain assets until the key is revoked on-chain.	Relayer services, end users, wallet developers	High	Relayer infrastructure must be treated as critical security boundary. Implement key rotation policies. Wallets should allow users to easily revoke specific relayer keys without disrupting their entire account.
Long-Term Dormant Key Risk	A user loses access to their primary key but has an old, forgotten full-access key on a lost device. An attacker who finds the device can take over the account, bypassing any recovery mechanisms.	End users, wallet developers, custodians	Medium	Wallets should periodically prompt users to review and prune active keys. Custodial services must have robust key rotation and forced revocation policies for compromised devices.

ACCESS KEY SECURITY HARDENING

Mitigation and Remediation Checklist

A systematic checklist for wallet developers, dApp teams, and security auditors to reduce the attack surface created by NEAR's flexible access key model. Each item identifies a specific risk vector, the verification signal, and the operational steps required to bring the system into a more secure posture.

What to check:

Query all AccessKey entries for every user account under your control or integration scope.
Identify keys with FullAccess permission that are not strictly required for account recovery or trusted automation.
Identify FunctionCall keys with overly permissive receiver_id lists or unlimited allowance.

Why it matters: Unrevoked full-access keys are a persistent backdoor. A key granted to a now-compromised dApp, a former team member, or a deprecated script can drain all assets at any time. Limited-access keys with excessive allowances can still cause significant financial damage.

Verification signal: A clean audit report showing zero unexpected FullAccess keys and all FunctionCall keys scoped to known, audited contract addresses with minimal allowances.

resource-links

NEAR ACCOUNT SECURITY REFERENCES

Canonical Resources and Standards

Use these sources to verify NEAR access key behavior, wallet integration patterns, and account-security controls before approving dApp permissions or changing signing flows.

NEAR access key model

Start with the official NEAR access key documentation when reviewing account-permission risk. NEAR accounts can hold multiple keys, and each key can be either full-access or function-call limited. Full-access keys can authorize broad account actions, while function-call keys are constrained by receiver account, method names, and allowance. Wallets, custodians, and dApps should treat this distinction as a primary security boundary: permission prompts, onboarding flows, and account-recovery UX must make clear which key type is being created and what actions it can authorize.

EXPLORE

nearcore implementation source

For protocol-accurate behavior, security teams should verify assumptions against nearcore, the canonical NEAR node implementation. Reviews of access-key risk should inspect how AddKey, DeleteKey, FunctionCall, Transfer, DeployContract, and related transaction actions are represented and validated. This is especially important for auditors assessing whether a wallet, relayer, custody platform, or contract integration has confused application-layer intent with protocol-layer authorization. If documentation and runtime behavior appear to diverge, nearcore and current network behavior should be treated as the authoritative implementation reference.

EXPLORE

NEAR RPC access key inspection

Operators should build key-audit workflows around NEAR RPC methods for viewing account keys and validating whether stale or high-privilege keys remain active. Risk teams can use access-key queries to inventory full-access keys, identify long-lived function-call keys, and check whether dApp-specific keys still point to receivers or methods that the user no longer uses. Wallets and custodians should expose this data in user-facing permission management, while exchanges and institutional operators should automate recurring checks for privileged keys on treasury, hot-wallet, and operational accounts.

EXPLORE

Wallet Selector integration surface

NEAR Wallet Selector is a key integration point for dApps that request wallet connections and account permissions. Teams using it should review how their application initiates sign-in, what permissions are requested, and whether users can distinguish limited dApp access from broader account control. Security reviews should test rejected permissions, reconnect flows, multiple-wallet behavior, and key cleanup after disconnect. A safe integration should prefer least-privilege function-call keys, avoid unnecessary full-access key requests, and document how users can revoke permissions from their wallet or account-management interface.

EXPLORE

near-api-js key management

Applications using near-api-js should review key storage, signer configuration, and environment separation. A common operational risk is treating development key-handling patterns as production-ready. Teams should avoid persisting powerful keys in browser storage, logs, CI variables, or unmanaged backend environments. For production systems, distinguish user-granted function-call keys from service keys, rotate keys on operator changes, and ensure testnet credentials cannot be reused in mainnet workflows. Auditors should trace how near-api-js constructs transactions and which key store supplies the signer for each account action.

EXPLORE

NEP repository for standards tracking

The NEAR Enhancement Proposals repository is the canonical place to monitor protocol and ecosystem standards that may affect wallet interoperability, account behavior, contract interfaces, and permission expectations. Access-key proliferation is not only a runtime issue; it is also shaped by wallet conventions, dApp standards, account abstraction patterns, and user-consent norms. Protocol architects should track relevant NEPs before adopting new signing or account-management patterns, and risk teams should verify whether a proposal is final, draft, or merely an ecosystem convention before treating it as a security baseline.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

ACCESS KEY SECURITY FAQ

Frequently Asked Questions

Common questions from wallet developers, security auditors, and integration teams about NEAR's access key model, its proliferation risks, and practical remediation strategies.

A full-access key can sign any transaction for the account, including transferring all assets, deploying contracts, and deleting the account itself. It effectively grants total control. A limited-access key, often called a function-call access key, is scoped to a specific contract and a set of allowed methods, with a configurable allowance for gas or token spending. The critical risk is that a malicious dApp requesting a full-access key can drain the account, while a compromised limited-access key restricts the attacker to the permissions explicitly granted. Wallet developers must ensure users understand this distinction before approving any key request.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Access Key Proliferation and Account Security Risks

The Double-Edged Sword of Flexible Access Keys

Access Key Risk Snapshot

How NEAR Access Keys Work

Who Is Affected

Wallet Developers