NEAR Protocol (NEAR): Nightshade Sharding, Access Keys, Staking and Indian VDA Tax

Summary: NEAR Protocol is a proof-of-stake blockchain whose native NEAR token is used for transaction fees, storage-related balances, staking and network participation. Its current public materials describe a sharded architecture called Nightshade, with stateless validation and dynamic resharding intended to distribute execution as network demand changes. NEAR accounts differ from simple address-only models: a named account can hold contract code, data and more than one access key, including restricted function-call keys. That flexibility improves application design but creates permission, phishing and account-recovery risks. Validators and delegators participate in network security, while staking returns remain variable and exposed to validator, protocol and token-price risk. Bridges, chain-signature systems and wrapped assets add dependencies that are not equivalent to holding native NEAR. For Indian taxpayers, a sale, token swap, spending event or conversion into another claim can require virtual digital asset analysis. The current law applies a special 30% rate to qualifying transfer income, restricts deductions and loss relief, and separately imposes 1% withholding on covered consideration under statutory conditions. This article explains the mechanics, records and legal boundaries without forecasting NEAR prices or recommending a wallet, exchange, validator or strategy.

NEAR Is a Native Asset on a Sharded Account-Based Network

NEAR is the native asset of the NEAR Protocol mainnet. It should not be confused with a bridged representation on another chain, a liquid-staking token, an exchange balance or a token that merely uses the same display symbol. Native NEAR is recorded in the protocol state and is used to pay execution fees, maintain storage-related balances, stake with validators and interact with applications. A custodial platform instead gives the customer a contractual account claim subject to that platform’s withdrawal, insolvency and compliance terms.

The protocol uses an account model in which an account record can contain a balance, locked stake, contract code, stored data and access keys. Human-readable account names improve usability but are not proof of identity, ownership or legal status. A transfer should be checked against the exact network, account ID and transaction payload. An apparently familiar suffix can still be controlled by someone else, and a sub-account is controlled through the key structure and contract rules rather than by the resemblance of its name.

Nightshade 3.0 Changes How Work Is Distributed

NEAR’s official blockchain page describes Nightshade as a horizontally scalable sharding design. Sharding divides network state and execution into parallel units while preserving a common security and coordination layer. The current page reports nine shards and describes live resharding, under which shards may split or merge as demand changes. Those statements describe network architecture and published capacity objectives; they do not guarantee a particular application response time, fee or uninterrupted access for every user.

Stateless Validation Reduces the State Burden on Validators

Nightshade 2.0 introduced stateless validation on mainnet. Instead of requiring every validator responsible for a shard to store its entire current state, block producers provide state witnesses containing the data required to verify execution. This can reduce hardware pressure and support more shards, but it adds witness generation, distribution and verification paths that must work correctly. A user still depends on protocol implementation, validator availability, data accessibility and the application contract being called.

Cross-Shard Receipts Are Not the Same as One Synchronous Database Call

A transaction can create receipts that are executed on another shard. Developers must account for asynchronous outcomes, callbacks, failed receipts and intermediate state. A wallet may show that the initiating transaction was included while a downstream application action is still pending or has failed. Users should keep the original transaction hash and inspect all related receipts before assuming that a deposit, swap or withdrawal completed. A user-interface success message is not a substitute for on-chain state.

Access Keys Make Permissions Granular but Easy to Misread

A NEAR account can have multiple keys. A full-access key can sign any transaction for the account, including transfers, key changes and contract deployment. A function-call key is restricted to specified contract calls and can include an allowance for gas. This design enables applications to offer limited sessions without exposing the master authority, but only if the permission is actually narrow and the user understands the contract and methods named in the approval.

A Restricted Key Can Still Cause Economic Loss

Function-call restrictions do not make an unknown application safe. An allowed method may spend tokens previously deposited in a contract, place orders, claim rewards or change application state. A malicious site can request a full-access key while presenting the action as a routine login. Before approval, the user should check whether the instruction adds a key, deletes a key, transfers NEAR or calls a contract; confirm the receiver account and method; and reject any seed-phrase request. Losing a device is different from losing the recovery material or leaving an unwanted key active.

Storage Staking Locks Balance for Account State

NEAR accounts and contracts must maintain enough balance for the storage they occupy. This storage-related balance is not a conventional fee paid once to a service provider; it remains tied to state usage and may become available when storage is released under the applicable contract and protocol logic. Contract storage deposits can also be managed through application-specific registration methods. A displayed wallet balance may therefore exceed the amount immediately transferable after storage and gas requirements are considered.

Staking Links Delegators to Validator and Protocol Outcomes

NEAR uses proof of stake. Validators stake tokens and operate infrastructure to produce and validate blocks or chunks under the protocol. A holder can delegate through a staking pool rather than run validator infrastructure. Delegation does not create a bank deposit, bond coupon or guaranteed return. Rewards depend on protocol issuance, participation, fees, validator performance, commission and the amount staked network-wide; the INR result also depends on the NEAR market price and taxes.

Withdrawal Is a Multi-Step State Change

Native staking pools generally distinguish between staked, unstaked and withdrawable balances. An unstake request must pass through the protocol’s waiting period before withdrawal, and the application or pool interface may require a separate withdrawal transaction. The live pool contract and current documentation should be checked rather than assuming that an exchange’s instant-withdrawal promise reflects native protocol mechanics. Exchange staking adds custody, internal-accounting and contractual risks beyond the staking pool.

Validator Review Is Broader Than a Reward Percentage

Commission, uptime, operational history, key management, software updates and governance participation all affect delegation risk, but none predicts future conduct. Protocol failures or penalties can reduce expected rewards or access. Concentrating stake can also affect network resilience. This article does not rank validators. A delegator should preserve the staking-pool account, amount, reward receipts, unstake requests, withdrawal transactions and any pool-specific terms.

Bridges, Chain Signatures and Private Execution Add New Trust Assumptions

NEAR materials describe chain-signature systems and connections to other networks. Such systems may let a NEAR account coordinate signatures or interact with assets on another chain, but the external asset remains governed by that chain, its contract and its custody or threshold-signature design. A bridge receipt or wrapped token is not automatically equivalent to native NEAR. Users should identify the issuer, locking contract, validator or signer set, redemption path and supported chain before moving value.

The current public page also describes a private shard connected through trusted-execution-environment infrastructure and operated by permissioned validators. Confidential execution changes visibility and trust assumptions; it does not make a transaction immune from law, operator failure, bridge risk or disclosure obligations. A taxpayer must preserve adequate off-chain records even when public-chain data does not reveal the full activity.

Indian VDA Tax Applies to Transfers, Not Merely Bank Withdrawals

Section 194 of the Income-tax Act, 2025 applies a 30% special rate, plus applicable surcharge and health and education cess, to income from the transfer of a virtual digital asset. The computation ordinarily permits only the cost of acquisition, if any, and denies other expenditure or allowance. A loss from transfer of a VDA cannot be set off against income under another provision or carried forward. Wallet-level profit or loss is therefore not a substitute for transaction-level computation.

Token Swaps and New Claims Need Disposal Analysis

Selling NEAR for rupees is a transfer. Swapping NEAR for another token, spending it, contributing it for a pool token, or exchanging native NEAR for a liquid-staking or wrapped claim can also create a transfer because one asset or right is given up for another. A movement between addresses under the same beneficial ownership may have a different character, but fees, wrappers, bridges and contract receipts must be identified. The INR fair value and cost lot should be documented at the event time.

The One Per Cent TDS Mechanism Is Separate

Section 393 contains the current withholding mechanism for consideration paid to a resident on transfer of a VDA. The rate is 1%, subject to statutory thresholds, payer classification and prescribed exchange procedures. It is a credit, not the final 30% tax. For relevant transactions after 1 April 2026, the Income Tax Department’s Form 141 framework applies to specified deductors under the new Act. Peer-to-peer and token-to-token transactions can require valuation and responsibility analysis even where no rupees are received.

GST, FEMA and PMLA Questions Depend on the Activity

GST does not follow from the NEAR ticker alone. Running validator infrastructure, providing custody, building software or supplying another service for consideration can create a supply analysis involving the supplier, recipient, place of supply, consideration and input-tax credit. An investor’s own disposal has different facts. Business records should separate token value from any separately charged service fee.

FEMA can be relevant when an Indian resident pays an offshore platform, supplies services abroad, transfers value to a non-resident or holds a claim governed by foreign law. The Liberalised Remittance Scheme is not blanket permission for overseas margin or margin-call payments. Under PMLA, service providers carrying out specified VDA activities for others can have FIU-IND registration and reporting duties. Registration of a provider does not approve NEAR, assure token value or guarantee withdrawal.

A NEAR Audit Trail Must Reconcile Keys, Receipts and Token Lots

• Inventory every native account, custodial account and foreign-chain representation, noting who controls the keys or contractual claim.
• Record transaction hash, block height, UTC and IST time, signer, receiver, method, deposit, gas, fees and every receipt outcome.
• Retain access-key additions and deletions, including full-access versus function-call permissions and allowance changes.
• Track storage deposits, staking pool balances, rewards, unstake requests, withdrawals and validator commission separately.
• Document each bridge or wrapper contract, source and destination chain, token address, redemption route and any failed message.
• Reconcile opening units plus purchases and rewards against disposals, transfers, fees and closing units, then match section 393 credits.

Frequently Asked Questions

1. Is a named NEAR account proof of the owner’s legal identity?

No. A readable account ID is a protocol identifier. Ownership depends on the account’s active keys and contract rules, not the name’s appearance.

2. What is Nightshade?

Nightshade is NEAR’s sharding architecture. Current official material describes stateless validation, nine shards and dynamic splitting or merging as demand changes.

3. Is a function-call key harmless because it cannot make an ordinary transfer?

No. It can invoke the permitted contract methods and may spend deposited assets or change economically important application state.

4. Is delegated NEAR immediately withdrawable?

Not necessarily. Native staking involves unstaking and a waiting period before withdrawal, while a custodial platform can impose different terms.

5. Is bridged NEAR the same legal and technical asset as native NEAR?

Not automatically. A wrapped representation adds contract, bridge, issuer, liquidity and redemption dependencies.

6. Can a NEAR-to-token swap be taxable in India without rupees being received?

Yes. Giving up one VDA for another can be a transfer requiring INR valuation and section 194 computation.

7. Does 1% TDS settle the final VDA tax?

No. Section 393 withholding is a credit on covered consideration. Transfer income and the 30% special-rate computation are separate.

8. Does FIU registration of an exchange make NEAR an approved investment?

No. AML registration concerns the provider’s obligations and is not approval of a token, price, custody arrangement or return.

Key Takeaways

• NEAR combines a native token, account records, multiple access-key types and sharded execution; each layer has different risks.
• Nightshade’s stateless and dynamic sharding claims do not guarantee a particular application’s completion time or safety.
• Native staking, custodial staking and liquid-staking claims are not interchangeable.
• Indian VDA tax is transaction-based; swaps, spending and new token claims can matter even without a bank withdrawal.
• Key permissions, cross-shard receipts, bridges, rewards and tax lots should reconcile in one evidence trail.

*****

Disclaimer: TaxGuru accepts no responsibility for any loss, tax shortfall, withholding failure, penalty, interest, inaccessible wallet, compromised key, failed receipt, bridge loss, staking loss, slashing event, storage lock, contract defect, platform insolvency, regulatory action or decision arising from reliance on this article or its source links. This material is a general educational description of NEAR Protocol and selected Indian legal and tax rules checked on 22 October 2026. It is not investment, legal, tax, accounting, cybersecurity, custody or technical advice and does not recommend, rank or endorse NEAR, any wallet, exchange, validator, staking pool, bridge, application or transaction. Protocol software, shard count, performance, access-key behavior, staking parameters, contract code, fees, tax law, forms and regulatory interpretations can change after publication. NEAR and related claims are volatile and can become illiquid or worthless. Full-access and function-call keys create different but material risks; a restricted permission can still cause economic loss. Bridges, wrapped assets, liquid-staking tokens, private execution and custodial balances add counterparties and rights that differ from native NEAR. Reader-specific consequences depend on residence, business status, beneficial ownership, transaction purpose, counterparty, cost evidence, receipt timing, accounting method, statutory thresholds, treaty position and whether a token movement creates a different asset or enforceable claim. Readers must verify live on-chain state and the latest official protocol, contract, tax, FIU, FEMA and service-provider material, preserve a transaction-level audit trail, and obtain advice from appropriately qualified legal, tax, accounting and cybersecurity professionals before acquiring, delegating, bridging, swapping, spending or reporting NEAR. Past network operation, published capacity or staking rewards do not predict future availability, security, price or tax treatment.