Choosing The Right Deployment Strategy for Smart Contracts on Near

This content originally appeared on DEV Community and was authored by Den

A new version of nearcore has recently been released on Near Protocol Mainnet. Among other changes, it introduces support for Global Contracts. This update solves a long-standing problem with contract deployment patterns and opens a new set of tools for developers. Now, we have multiple fundamentally different options for deploying the same contract logic. The best choice depends entirely on your app’s architecture and user experience goals.
This article will walk you through those options, and by the end, you’ll know which questions to ask yourself to choose the most suitable strategy for your project.

The Classic Way

This is the default and most familiar pattern. You deploy a smart contract to a Near account by sending a transaction with the DeployContract action, which includes the compiled WebAssembly code. The contract is deployed to the same account from which the transaction was sent. For example, deploying to contract.testnet means the code now lives and runs under that exact account.

A few key points to remember:

• The contract code is stored directly in the account’s state.
• The account is charged for using the storage at the rate of 1 NEAR per 100 KB, so a 500 KB contract will lock 5 NEAR on that account.
• This locked amount is not spent — it can be recovered by deleting or replacing the contract with a smaller one.

This is important because if you deploy the same 500 KB contract to three accounts, each pays 5 NEAR for the storage — a total of 15 NEAR is locked just to hold the identical code. This redundancy is what Global Contracts aim to eliminate.

Global Contracts

Global Contracts are reusable, globally-accessible smart contracts. Instead of every user or app deploying its own copy, a Global Contract is deployed once and then referenced by many accounts.

There are two types of Global Contracts:

a. By Hash – An immutable contract is deployed globally and identified by its code hash.

b. By Account ID – An upgradable contract is published globally under a specific account ID.

Global Contracts work through two new transaction actions: DeployGlobalContract and UseGlobalContract. First, a developer deploys a smart contract by sending a transaction with the DeployGlobalContract action, which contains the compiled WebAssembly code and makes it available either by its code hash or by a specific account ID. This is a one-time, global publication — the contract doesn’t run under the sender’s account, but instead becomes available for others to reference.

To use that contract, another user or application sends a transaction with the UseGlobalContract action, referencing the Global Contract either by code hash, or account ID.

• The contract code is distributed across all shards in the Near Protocol network, not stored inside any specific account’s storage.
• The account is charged 10x more for deploying a Global Contract, at the rate 10 NEAR per 100KB.
• This amount is entirely burnt and cannot be recovered later, unlike regular deployments where Near is simply locked.
• It costs almost nothing for a user to UseGlobalContract as there’re only a few bytes for the reference that are stored in the account’s storage, the total fee is typically under 0.001 NEAR.

You Can Use Both on One Account

There’s nothing stopping you from deploying both a regular contract and a Global Contract by Account ID on the same Near account. Let’s say Contract A is deployed as a Global Contract, and Contract B is a traditional contract on the same account. They coexist independently. The order of deployment also doesn’t matter.

How to Choose the Right Strategy

Ask yourself the following essential questions before deciding how to deploy your contracts:

1. Are you working in a local environment?
   If you’re just testing or building a prototype, regular deployments are simpler and more flexible. There’s no need to burn tokens or register global references — just deploy and iterate.

2. Is the contract supposed to be deployed on many accounts?
   If the same contract will be reused across many independent accounts — say, 10 or more — Global Contracts can significantly reduce overall cost and complexity. But if only a few accounts are involved, regular deployment remains the more economical choice.

3. Are these accounts managed by your team?
   If all target accounts are under your infrastructure, you may prefer regular deployments for flexibility and cost recovery.
   3.1 Are there more than 10 accounts?
   Global Contracts become financially efficient when reused at scale. If you’re deploying the same contract to more than 10 accounts, it’s likely worth considering.
   3.2 Do you need to upgrade the contract across many accounts in one step, even if it requires burning tokens?
   If you want to be able to push updates to all deployed instances at once, then go with Global Contracts by Account ID, but keep in mind that the deployment cost is non-refundable.

4. Does your use case require the contract to be permanently immutable?
   If the contract must never change, for example, due to security, compliance, or user trust, then using a Global Contract by Code Hash ensures immutability at the protocol level.

Real-World Examples

To make this concrete, let’s look at several practical scenarios and how each maps to the right deployment strategy.

— Guestbook App

A minimal app that lets users leave public messages.
It uses just one contract deployed under the app’s own account, with no need for reuse, upgrades, or external deployments. Since this is an internal deployment in a local environment, regular deployment is the simplest and most appropriate option.

— DeFi Protocol with On-Chain Oracles

An infrastructure-heavy application with multiple smart contracts handling liquidity, pricing, and execution.
All contracts are deployed and maintained by the core team, and only used within the project’s ecosystem. Since the number of deployments is limited, upgradability is needed, and storage costs should be recoverable, the best fit is regular deployment.
However, if the protocol deploys a large number of identical oracle contracts and wants the ability to upgrade them all centrally, it may be more efficient to use a Global Contract with reference by Account ID.

— DAO Factory

A tool that allows any user to deploy their own DAO governance instance.
The same contract is deployed many times by end users across different accounts. This clearly meets the threshold where Global Contracts become financially efficient. Since upgradeability may be useful down the line (e.g. to patch bugs or extend functionality), the right choice is Global Contract by Account ID.

— NFT Collection Factory

A service that lets users create their own NFT contracts with fixed metadata and royalty.
Each user deploys the same contract, but once deployed, it should never be changed — security and immutability are critical here. This makes Global Contract by Hash the best match.

Thanks for reading. I hope this helped clarify when and why to use Global Contracts on Near. If it did — share it, comment, and let others in the ecosystem know.

This content originally appeared on DEV Community and was authored by Den