Astar
Astar connects smart contracts with staking support for dApps.
Last updated
Astar runs smart contracts on Polkadot and lets ASTR holders support eligible decentralized applications through dApp staking. These applications use blockchain programs to manage assets and execute transactions. Using an application, deploying a contract, and staking on a project involve different permissions and balances. ASTR pays network transaction fees and participates in staking. Choosing the right account format and keeping transferable funds available are practical requirements across these activities.
Using an application and supporting its development are separate activities
If your task involves an application’s assets or functions, you need the account and permissions that its contracts accept. EVM applications use the Ethereum Virtual Machine, which executes compatible contract code. A token exchange changes contract state; a read-only query retrieves information without changing it.
dApp staking allocates locked ASTR to registered projects within a network incentive system. Stakers and eligible developers receive separate rewards under its rules. Allocating stake doesn’t purchase an application’s token, create an ownership share, or deposit assets into its product. Running an application and supporting its development are separate choices.
Account format and available ASTR affect which transactions can succeed
Native and EVM accounts
The receiving service’s supported account format determines which address you should provide. Native Substrate accounts use SS58 addresses; EVM accounts use Ethereum-style H160 addresses. The network maps EVM accounts into its native balance system, but that mapping doesn’t make separately created accounts interchangeable.
A wallet can display both account types without combining their balances. Before transferring funds, match the destination’s network and address requirements. A service that accepts native deposits may not accept an EVM transfer through the same deposit instructions.
Transferable funds and locked funds
Keep transaction fees separate from the amount committed to staking. Locked tokens can’t pay fees or move to another account. A large total balance can therefore coexist with insufficient transferable funds for a transaction.
Fee requirements also depend on the operation. Native calls consume resources measured through transaction weight; EVM execution uses gas accounting. A contract call can consume more resources than a simple transfer, so a previous transaction’s cost isn’t a reliable allowance for a different operation.
Project allocations connect locked tokens to staking rewards
Locking and allocating
Participation requires both an eligible locked balance and an allocation to a registered dApp. Claim any pending rewards before submitting a stake or unstake transaction. Locking tokens alone doesn’t earn dApp staking rewards. The protocol distinguishes the amount reserved for staking from the amount assigned to projects.
Minimum lock and stake requirements govern whether an allocation is valid. These are network parameters, so treat the values displayed for the selected network as live inputs. Dividing an otherwise sufficient balance into allocations below the applicable minimum won’t create valid stakes.
Reward timing and period renewal
Staking rewards use eras, the protocol’s accounting intervals. A submitted allocation doesn’t immediately produce claimable rewards. An allocation takes effect in the next era. Rewards become claimable after a full eligible era in the Build&Earn subperiod; the Voting subperiod earns no rewards.
Tokenomics 3.0 removed the earlier user-facing bonus reward feature. Stakes also reset when a new staking period begins, while token locks remain. Continuing participation therefore requires a fresh allocation for the new period. An unchanged locked balance doesn’t confirm that the account is earning.
An allocation below the minimum needs a larger amount before retrying
In this hypothetical example, an account has sufficient locked ASTR, separate transferable funds for fees, and a selected registered project. Its attempted allocation falls below the live minimum, so the staking call fails without recording that allocation.
The account holder can increase the allocation using the existing locked balance or leave that balance unallocated. Both options turn on the same requirement: earning through the selected project requires a valid stake. Leaving tokens locked without allocating them doesn’t satisfy that requirement.
The holder chooses to retry. Let M represent the minimum stake returned by the network. The replacement allocation equals M and fits within the available locked balance. The allocation must meet the minimum in force when the transaction executes; network configuration can change M.
After the replacement transaction succeeds, the staking record shows the selected project and accepted amount for the current period. That confirms the allocation. Reward accrual still follows the era schedule, so an initially empty claimable-rewards field doesn’t establish another failure.
EVM contracts connect application logic to network functions
Deployment and application permissions
Solidity contracts can target the EVM environment, allowing developers to use familiar contract tooling. Compatibility still requires testing the contract’s deployment size, configuration, and dependencies against the destination network. A successful deployment elsewhere doesn’t establish that the same configuration will work unchanged.
Deployment creates the application contract; subsequent calls execute its functions. The signing account needs the permissions that those functions require. Contract execution also remains subject to network resource limits, which can affect deployment and operation.
Access to native staking functions
Precompiles expose selected native functions to EVM contracts through defined interfaces. The dApp staking precompile provides access to the staking pallet, the runtime module that manages staking. New integrations should use the V3 interface and follow its operation requirements; older examples may use the deprecated but still supported V2 interface.
Cross-chain transfers depend on asset support at both ends
XCM, the cross-consensus message format, supports communication within the Polkadot ecosystem. A usable transfer requires a supported asset and destination, suitable account addressing, and enough funds for the applicable costs. A shared token ticker doesn’t establish that every network representation follows the same transfer route.
Some native assets appear in EVM applications through XC20 interfaces. These provide ERC-20-compatible access to assets managed by the native runtime. Asset-specific minimum balances still apply. If a transfer would leave the sender with a positive balance below the minimum, the actual amount transferred may exceed the requested amount.
WASM migration and the retired zkEVM require different treatment
New smart-contract work must account for the WASM sunset. Runtime-2207 froze new WASM uploads, instantiation, and upgrades. Existing-contract migration and final removal are separate events. The announced removal process requires governance and a subsequent runtime upgrade; a proposed removal date doesn’t prove completion. Affected projects also need to handle staking unregistration and developer reward claims.
The separate Astar zkEVM network was deprecated on March 31, 2025. Its bridges and transaction endpoints shut down. That retirement concerned a different network from the Polkadot parachain’s EVM environment, so the two names mustn’t be treated as interchangeable destinations.
Polkadot validation and application correctness cover different risks
Polkadot validators validate blocks proposed by Astar collators. This shared security underpins the parachain’s accepted history. Application code determines what a valid transaction actually does, including its permissions and asset movements. Consensus can faithfully execute a flawed contract, so network security doesn’t establish the correctness of every application.
Staking commitments differ from keeping ASTR transferable
Staking rewards come from token emissions and protocol allocations, rather than a fixed payment attached to each token. Governance can change economic parameters, including emission settings and reward distribution. Project reward eligibility also depends on staking support and the tier rules. A displayed return shouldn’t become a permanent assumption in an application’s accounting.
Exiting involves more than removing a project allocation. Tokens must pass through the unlocking process before withdrawal into the free balance. The protocol also limits simultaneous unlocking chunks, which are separate amounts awaiting release. Maintaining an account therefore includes reviewing allocations, claiming rewards, and tracking amounts awaiting withdrawal.
Keeping ASTR transferable preserves immediate access for fees and supported transfers. Committing it to dApp staking introduces reward eligibility and an unlocking delay. The suitable choice follows whether the balance needs to remain spendable or can remain committed under those rules.
Things people ask about Astar
Does deploying a contract automatically qualify a project for dApp staking?
Deploying a contract doesn’t automatically admit a project to dApp staking. Projects require governance approval to join the program. Registration and reward eligibility are also separate: developer rewards depend on the applicable tier requirements and staking support. A deployed application can operate without receiving those rewards.
How long can staking rewards remain unclaimed?
Unclaimed rewards remain available only within the protocol’s reward retention window. The network expresses this window in staking periods, after which rewards expire. Retention is a configurable parameter, so an account shouldn’t treat an old claimable balance as permanently recoverable.
Is wrapped ASTR the same asset as native ASTR?
Wrapped ASTR represents native ASTR through an ERC-20-compatible contract. Its interface lets applications handle it as a token contract, while native ASTR serves network functions such as paying transaction fees. Multiple WASTR implementations exist, so the contract that an application accepts matters alongside the ticker.
Why does a deployment request return 403 Forbidden?
A 403 response from a network endpoint can indicate that the endpoint has restricted the request. Public endpoints impose request limits and aren’t intended for sustained indexing workloads. An endpoint rejection doesn’t, by itself, show that the contract failed during execution.
Where can an XC20 transfer appear when an EVM explorer doesn’t show it?
An XC20 transfer submitted through the Substrate API can appear in native chain records without appearing in an EVM explorer’s transaction history. The interface used to submit the transfer determines which records to inspect. Absence from the EVM transaction list alone doesn’t establish that the asset never moved.
Are wallet account names visible to other people on the blockchain?
A locally assigned wallet account name isn’t necessarily recorded on the blockchain. For example, the native account creation flow keeps its descriptive account name local. The public address remains visible, so a private wallet label doesn’t make the account’s blockchain activity anonymous.