You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor contract-deployment.md to focus on theoretical guidance
Replace practical tool commands with conceptual content covering:
- Deployment model (CREATE/CREATE2 opcodes)
- Transaction processing architecture
- Gas estimation behavior and multi-dimensional resource model
- Storage model and deposits
- Address derivation algorithms
- Finality considerations
This aligns the page with the for-eth-devs section's purpose of providing
theoretical guidance rather than practical how-to instructions.
description: Learn how to deploy Solidity smart contracts to Polkadot Hub using familiar Ethereum tooling and workflows.
3
+
description: Understand how smart contract deployment works on Polkadot Hub compared to Ethereum, including transaction processing, gas estimation, and storage considerations.
Deploying smart contracts to Polkadot Hub works exactly like deploying to Ethereum. Use your existing Solidity contracts, familiar tools like Hardhat, Foundry, or Remix, and deploy without any modifications.
12
+
Smart contract deployment on Polkadot Hub follows the same conceptual model as Ethereum. This page explains the underlying mechanisms and key behavioral differences that Ethereum developers should understand when deploying contracts to Polkadot Hub.
13
13
14
-
## Deployment Process
14
+
## Deployment Model
15
15
16
-
Polkadot Hub uses the REVM backend, which provides full Ethereum compatibility. This means:
16
+
Polkadot Hub uses the REVM backend, which implements the Ethereum Virtual Machine specification. This means deployment transactions are processed identically to Ethereum:
17
17
18
-
-**Single-step deployment**: Contracts deploy in a single transaction, just like Ethereum.
19
-
-**Factory patterns work**: Create new contracts at runtime using standard factory patterns.
20
-
-**Full Solidity support**: All Solidity features including inline assembly are supported.
21
-
-**Familiar tools**: Hardhat, Foundry, Remix, and other Ethereum tools work out of the box.
18
+
-**CREATE opcode**: Deploys contracts to deterministic addresses based on sender and nonce
19
+
-**CREATE2 opcode**: Enables counterfactual deployment with salt-based address derivation
20
+
-**Constructor execution**: Runs initialization code and returns runtime bytecode
21
+
-**Factory patterns**: Contracts can deploy other contracts at runtime without restrictions
22
22
23
-
## Using Your Existing Workflow
23
+
The deployment transaction contains the contract's initialization bytecode in the `data` field, and the EVM executes this code to produce the runtime bytecode stored on-chain.
This architecture means your deployment transactions look and behave exactly like Ethereum transactions from the client perspective, while benefiting from Polkadot's consensus and finality guarantees.
36
36
37
-
### With Remix
37
+
##Gas Estimation Behavior
38
38
39
-
1. Connect MetaMask to Polkadot Hub
40
-
2. Select "Injected Provider - MetaMask" in Remix
41
-
3. Deploy as you would to any EVM chain
39
+
Ethereum developers may notice that gas estimates on Polkadot Hub are higher than actual consumption. This is expected behavior stemming from architectural differences:
42
40
43
-
##Gas Estimation
41
+
### Why Estimates Differ
44
42
45
-
You might notice that gas estimates are higher than actual consumption (often around 30% of the estimate is used). This is normal behavior because:
43
+
Polkadot's runtime uses a multi-dimensional resource model:
46
44
47
-
-Pre-dispatch estimation cannot distinguish between computation weight and storage deposits
48
-
-Contract deployments consume significant storage deposits for code storage
49
-
-The system uses conservative overestimation to ensure transactions succeed
45
+
-**Computation weight** - Processing time consumed by the transaction
46
+
-**Proof size** - Data required for light client verification
47
+
-**Storage deposits** - Refundable deposits for on-chain storage
50
48
51
-
## Network Configuration
49
+
When you call `eth_estimateGas`, the system must return a single gas value that covers all three dimensions. Since pre-dispatch estimation cannot perfectly predict the breakdown between computation and storage, the system uses conservative overestimation.
| Block Explorer |[BlockScout](https://blockscout-passet-hub.parity-testnet.parity.io/){target=\_blank} |
53
+
- Estimates may show 3x the actual gas consumed
54
+
- Transactions still succeed because the estimate provides sufficient headroom
55
+
- Actual costs are based on real consumption, not the estimate
56
+
- Unused gas is refunded as on Ethereum
62
57
63
-
## Next Steps
58
+
This behavior does not affect transaction success or final costs—it only means the estimated values appear higher than what you might expect from Ethereum mainnet.
64
59
65
-
Once deployed, your contracts can:
60
+
## Storage Model
66
61
67
-
- Interact with other contracts on Polkadot Hub
68
-
- Access Polkadot-native functionality via [precompiles](/smart-contracts/precompiles/)
69
-
- Communicate cross-chain using [XCM](/smart-contracts/precompiles/xcm/)
62
+
Contract deployment consumes storage for:
63
+
64
+
-**Code storage** - The runtime bytecode is stored on-chain
65
+
-**Account creation** - A new account entry is created for the contract
66
+
-**Initial state** - Any storage slots set during construction
67
+
68
+
Polkadot Hub uses a storage deposit system where deployers pay a refundable deposit proportional to the storage consumed. This deposit is returned when the contract is destroyed and storage is freed.
69
+
70
+
## Address Derivation
71
+
72
+
Contract addresses are derived using the same algorithms as Ethereum:
73
+
74
+
| Method | Address Calculation |
75
+
|--------|-------------------|
76
+
| CREATE |`keccak256(rlp([sender, nonce]))[12:]`|
77
+
| CREATE2 |`keccak256(0xff ++ sender ++ salt ++ keccak256(init_code))[12:]`|
78
+
79
+
This means you can predict deployment addresses using the same tools and techniques as on Ethereum.
80
+
81
+
## Finality Considerations
82
+
83
+
Unlike Ethereum's probabilistic finality, Polkadot provides deterministic finality through its GRANDPA consensus mechanism. Once a block containing your deployment is finalized:
84
+
85
+
- The contract deployment is irreversible
86
+
- No chain reorganization can remove the contract
87
+
- Finality typically occurs within seconds, not minutes
88
+
89
+
This faster finality means you can begin interacting with deployed contracts more quickly and with stronger guarantees than on Ethereum.
90
+
91
+
## Where to Go Next
92
+
93
+
For step-by-step deployment tutorials using specific tools, see:
94
+
95
+
-[Deploy with Remix](/smart-contracts/cookbook/smart-contracts/deploy-basic/basic-remix/) - Browser-based deployment walkthrough
96
+
-[Hardhat Setup](/smart-contracts/dev-environments/hardhat/) - Local development environment configuration
description: Learn how to deploy Solidity smart contracts to Polkadot Hub using familiar Ethereum tooling and workflows.
3
+
description: Understand how smart contract deployment works on Polkadot Hub compared to Ethereum, including transaction processing, gas estimation, and storage considerations.
4
4
categories: Smart Contracts, Basics
5
5
---
6
6
7
7
# Contract Deployment
8
8
9
9
## Introduction
10
10
11
-
Deploying smart contracts to Polkadot Hub works exactly like deploying to Ethereum. Use your existing Solidity contracts, familiar tools like Hardhat, Foundry, or Remix, and deploy without any modifications.
11
+
Smart contract deployment on Polkadot Hub follows the same conceptual model as Ethereum. This page explains the underlying mechanisms and key behavioral differences that Ethereum developers should understand when deploying contracts to Polkadot Hub.
12
12
13
-
## Deployment Process
13
+
## Deployment Model
14
14
15
-
Polkadot Hub uses the REVM backend, which provides full Ethereum compatibility. This means:
15
+
Polkadot Hub uses the REVM backend, which implements the Ethereum Virtual Machine specification. This means deployment transactions are processed identically to Ethereum:
16
16
17
-
-**Single-step deployment**: Contracts deploy in a single transaction, just like Ethereum.
18
-
-**Factory patterns work**: Create new contracts at runtime using standard factory patterns.
19
-
-**Full Solidity support**: All Solidity features including inline assembly are supported.
20
-
-**Familiar tools**: Hardhat, Foundry, Remix, and other Ethereum tools work out of the box.
17
+
-**CREATE opcode**: Deploys contracts to deterministic addresses based on sender and nonce
18
+
-**CREATE2 opcode**: Enables counterfactual deployment with salt-based address derivation
19
+
-**Constructor execution**: Runs initialization code and returns runtime bytecode
20
+
-**Factory patterns**: Contracts can deploy other contracts at runtime without restrictions
21
21
22
-
## Using Your Existing Workflow
22
+
The deployment transaction contains the contract's initialization bytecode in the `data` field, and the EVM executes this code to produce the runtime bytecode stored on-chain.
This architecture means your deployment transactions look and behave exactly like Ethereum transactions from the client perspective, while benefiting from Polkadot's consensus and finality guarantees.
35
35
36
-
### With Remix
36
+
##Gas Estimation Behavior
37
37
38
-
1. Connect MetaMask to Polkadot Hub
39
-
2. Select "Injected Provider - MetaMask" in Remix
40
-
3. Deploy as you would to any EVM chain
38
+
Ethereum developers may notice that gas estimates on Polkadot Hub are higher than actual consumption. This is expected behavior stemming from architectural differences:
41
39
42
-
##Gas Estimation
40
+
### Why Estimates Differ
43
41
44
-
You might notice that gas estimates are higher than actual consumption (often around 30% of the estimate is used). This is normal behavior because:
42
+
Polkadot's runtime uses a multi-dimensional resource model:
45
43
46
-
-Pre-dispatch estimation cannot distinguish between computation weight and storage deposits
47
-
-Contract deployments consume significant storage deposits for code storage
48
-
-The system uses conservative overestimation to ensure transactions succeed
44
+
-**Computation weight** - Processing time consumed by the transaction
45
+
-**Proof size** - Data required for light client verification
46
+
-**Storage deposits** - Refundable deposits for on-chain storage
49
47
50
-
## Network Configuration
48
+
When you call `eth_estimateGas`, the system must return a single gas value that covers all three dimensions. Since pre-dispatch estimation cannot perfectly predict the breakdown between computation and storage, the system uses conservative overestimation.
| Block Explorer |[BlockScout](https://blockscout-passet-hub.parity-testnet.parity.io/){target=\_blank} |
52
+
- Estimates may show 3x the actual gas consumed
53
+
- Transactions still succeed because the estimate provides sufficient headroom
54
+
- Actual costs are based on real consumption, not the estimate
55
+
- Unused gas is refunded as on Ethereum
61
56
62
-
## Next Steps
57
+
This behavior does not affect transaction success or final costs—it only means the estimated values appear higher than what you might expect from Ethereum mainnet.
63
58
64
-
Once deployed, your contracts can:
59
+
## Storage Model
65
60
66
-
- Interact with other contracts on Polkadot Hub
67
-
- Access Polkadot-native functionality via [precompiles](/smart-contracts/precompiles/)
68
-
- Communicate cross-chain using [XCM](/smart-contracts/precompiles/xcm/)
61
+
Contract deployment consumes storage for:
62
+
63
+
-**Code storage** - The runtime bytecode is stored on-chain
64
+
-**Account creation** - A new account entry is created for the contract
65
+
-**Initial state** - Any storage slots set during construction
66
+
67
+
Polkadot Hub uses a storage deposit system where deployers pay a refundable deposit proportional to the storage consumed. This deposit is returned when the contract is destroyed and storage is freed.
68
+
69
+
## Address Derivation
70
+
71
+
Contract addresses are derived using the same algorithms as Ethereum:
72
+
73
+
| Method | Address Calculation |
74
+
|--------|-------------------|
75
+
| CREATE |`keccak256(rlp([sender, nonce]))[12:]`|
76
+
| CREATE2 |`keccak256(0xff ++ sender ++ salt ++ keccak256(init_code))[12:]`|
77
+
78
+
This means you can predict deployment addresses using the same tools and techniques as on Ethereum.
79
+
80
+
## Finality Considerations
81
+
82
+
Unlike Ethereum's probabilistic finality, Polkadot provides deterministic finality through its GRANDPA consensus mechanism. Once a block containing your deployment is finalized:
83
+
84
+
- The contract deployment is irreversible
85
+
- No chain reorganization can remove the contract
86
+
- Finality typically occurs within seconds, not minutes
87
+
88
+
This faster finality means you can begin interacting with deployed contracts more quickly and with stronger guarantees than on Ethereum.
89
+
90
+
## Where to Go Next
91
+
92
+
For step-by-step deployment tutorials using specific tools, see:
93
+
94
+
-[Deploy with Remix](/smart-contracts/cookbook/smart-contracts/deploy-basic/basic-remix/) - Browser-based deployment walkthrough
95
+
-[Hardhat Setup](/smart-contracts/dev-environments/hardhat/) - Local development environment configuration
0 commit comments