Nearprotocol Nearprotocol for Transfers and Apps
NEAR Protocol is a layer-one blockchain for asset transfers and smart-contract apps. Full-access keys authorize native NEAR transfers; function-call keys restrict calls to one contract and cannot attach NEAR. A relayer can pay gas for the actions it agrees to sponsor, while the client account still supplies any transferred NEAR or attached deposit and covers its storage requirements.
Task Fit and Required Capabilities
| Use | Required Access or Service | Outcome to Inspect | Main Constraint |
|---|---|---|---|
| Native NEAR transfers | Full-access signing authority for a standard direct transfer | Successful execution of the intended transfer on the selected network | The signing key also has authority to change keys or delete the account. |
| Repeated app calls | A key authorized to call the contract; a function-call key can restrict access | The method's execution outcome and any relevant application state | A function-call key cannot attach NEAR or directly manage account keys. |
| Sponsored app transactions | An existing client account, a signed delegate and an accepting relayer on the same network | Execution of the delegated actions after submission to NEAR | The client still funds attached deposits or transferred NEAR and meets storage requirements. |
| Contract-based app development | Contract development tools and any frontend integration the app needs | Deployment and contract-call outcomes in the chosen environment | Developers maintain contract behavior and the integration; compilation alone does not establish runtime results. |
Native Transfers and Account Readiness
Transfer authority and contract-call permission support different actions. A full-access key can authorize a direct transfer of native NEAR. A function-call key cannot authorize that native transfer action. Contract-mediated asset movement depends on the methods the deployed contract exposes.
ED25519 implicit accounts have 64-character hexadecimal addresses derived locally before the accounts exist on-chain. In the implicit-account creation flow, the first transfer creates the account, including when the transferred amount is 0 NEAR. The sender pays a 0.007 NEAR creation charge through gas plus other transaction fees. The new account must exist on-chain before it can send transactions, including meta-transactions.
Storage coverage is separate from the transfer amount and transaction fees. Under the documented zero-balance account rules, the creation charge covers storage for accounts using 770 bytes or less. Accounts exceeding 770 bytes must reserve a balance for all their stored data, including the first 770 bytes, at the documented rate of 0.00001 NEAR per byte. Integrations can query the network's storage price through
protocol_config
. Deleting data lowers the storage requirement, making any balance no longer needed for storage available.
Function-Call Keys for Repeated App Use
Reusable app access can be limited to a specific contract. A function-call key's
receiver_id
selects that contract, while an optional
method_names
list restricts the permitted methods. If the method list is omitted, the key can call every method on that contract. An app call requiring an attached NEAR deposit needs signing authority permitting that deposit.
Gas allowance controls a separate limit. Omitting
allowance
leaves the key without a gas budget restriction. Once a configured gas budget is exhausted, adding NEAR to the account does not restore the key's allowance. The existing allowance cannot be changed; a full-access key or a method in the account's own contract must add a replacement key. Deleting an app's function-call key revokes its on-chain call permissions.
Account management needs a usable access path beyond restricted app calls. An account left with only function-call keys cannot directly transfer native NEAR or replace its keys through standard account actions. A previously deployed account contract may provide suitable management methods. If the only full-access private key is lost, potential recovery requires an account contract with an implemented recovery method; recovery is not the default.
Gas Sponsorship and Repeated Calls
Meta-transactions separate action signing from gas payment. The user signs a delegate action containing the sender, receiver, actions, nonce and expiry block height. The relayer receives the signed delegate and submits it using its own funded account, without receiving the user's private key.
The client account must already exist on-chain and cover its storage requirements. Client and relayer must use the same network. A wallet must support delegate-action signing for this flow: ordinary transaction signing and NEP-413 message signing produce different payloads and cannot replace it.
The relayer chooses which calls to sponsor and can restrict senders, contracts, methods and arguments. Its operator maintains the service and gas funding. Any attached deposit or transferred NEAR still comes from the client account, so sponsored gas does not remove those funding requirements.
Repeated delegated calls from the same client key need nonce coordination. The relayer guide recommends waiting for one delegated call to finish before signing the next with that key. Rotating the relayer's own keys does not change the client's delegate nonce. Signing authorizes the actions; signing alone does not broadcast or complete them.
Contract-Based App Development
NEAR's WebAssembly runtime supports contracts written in Rust or JavaScript. Frontend integrations can authenticate users through wallets and call contract methods. Token, NFT and DAO applications use application-specific contract logic, so their useful outcomes depend on the deployed methods and the permissions those calls require.
Testnet accounts and faucet tokens support development in the testnet environment. Deployment and contract-call results must be interpreted within that environment; they do not establish a mainnet deployment. Developers maintain the contract and its frontend integration as methods or permission requirements change.
Cross-Chain and Confidential App Needs
NEAR Intents can coordinate a desired asset exchange across liquidity sources. Chain Signatures enables NEAR accounts, including smart contracts, to sign transactions for other blockchains. Intents can use that signing infrastructure, so both capabilities can contribute to the same application. The chosen integration determines which assets, networks and actions are available.
Confidential Intents uses the NEAR private shard. Its Nightshade 3.0 configuration uses seven permissioned validators and a bridge based on trusted execution environments (TEEs) to connect to NEAR mainnet. Confidentiality belongs to transactions using that private execution path; an ordinary NEAR account or wallet connection does not establish confidential transfers.