Page 1 of 1
EVM Smart contract deployment workflows: pain points and unmet needs
We're trying to understand where current evm smart contract deployment tools fall short, especially for teams using or evaluating hardhat-deploy. This survey takes less than 5 minutes.
What is missing from current deployment tools for your use case?
What do you build?
*
What do you build?
DeFi / finance
NFT / collectibles
Fully onchain game
Consumer app
Infrastructure / protocol
Other
What project(s) you are working on
What is your main deployment workflow today?
*
What is your main deployment workflow today?
A
hardhat-deploy v1
B
hardhat-deploy v2 / rocketh
C
MUD
D
forge scripts
E
custom scripts
F
Hardhat Ignition
G
other
Which of these are part of your current setup?
*
Which of these are part of your current setup?
Upgradeable contracts / proxies
Multi-contract system
Frontend needs deployment data synced automatically
Local-first or offline development matters
Hardhat 3
MUD framework
Proxy for dev and immutable on mainnet
Hardhat 2
Fully onchain game requirements
Hardhat Ignition
hardhat-deploy v2 / rocketh
I am actively evaluating alternatives
Foundry / forge scripts
hardhat-deploy v1
Other
Which best describes your hardhat-deploy usage?
*
Which best describes your hardhat-deploy usage?
A
I was not aware v2 existed
B
I know v2 exists but have not looked into it
C
I looked into it but migration cost was too high
D
I tried it and stayed on v1
E
I currently use v2
F
I used hardhat-deploy before, but not now
If you're on hardhat-deploy v1, what keeps you there?
*
If you're on hardhat-deploy v1, what keeps you there?
It works, no reason to change
Features I rely on aren't in v2 yet
Migration path isn't clear
v2/rocketh API is too different
I wasn't aware v2 existed
Not applicable (I don't use v1)
Other
What matters in your deployment workflow?
*
What matters in your deployment workflow?
Flexibility for deployments
Recovering from interrupted deployments
Simplicity
Repeatability across environments
Ability to execute deployment in browser
Full TypeScript type safety for deployments
Local simulation / local-first workflow
Deploy tags for partial/selective deployments
Reusing deployment logic in tests
Named accounts / role-based deployment configuration
Deployment tracking
Contract verification
Stability of api
Live reload (auto-redeploy on contract changes during dev)
Deterministic deployments
Declarative Proxy Deployment (no manual upgrade specification)
Faster iteration during development
Large Contract System Handling (Diamond, MUD world, router, ...)
Mud world contract support
Frontend integration / exporting deployment data
independence of framework (foundry, hardhat) upgrades
Speed
Other
Which best describes your position on Ignition?
*
Which best describes your position on Ignition?
A
I use it as my main deployment workflow
B
I tried it and did not adopt it
C
I investigated it, but did not try it seriously
D
I know about it, but have not evaluated it
E
It is not really on my radar
F
Other
If Ignition is not your main deployment workflow, why not?
*
If Ignition is not your main deployment workflow, why not?
I need better frontend / app integration
I need better support for complex multi-contract systems (Diamonds, MUD world...)
My current setup already works well enough
I tried it and it did not feel ready for my use case
I need stronger test and deployment reuse
Migration cost is too high
I have not spent enough time evaluating it yet
I need better upgrade / proxy support
I need more flexibility than the current model offers
Other
In the last few months, what have you spent time investigating as alternatives or changes?
*
In the last few months, what have you spent time investigating as alternatives or changes?
Hardhat Ignition
forge scripts
Moving from hardhat-deploy v1 to v2
custom deployment scripts
no serious investigation recently
MUD framework
Other
What frustrates you most about your current setup?
*
What frustrates you most about your current setup?
Hard to manage multiple signers/roles across environments
Local development experience is weak
Locked into a specific framework's contract architecture
Too much boilerplate
Deployment state is brittle or gets corrupted
Frontend integration is painful
Migration cost is too high
Upgrades / proxies are awkward
Docs / examples are not good enough
Tooling feels incomplete or unstable
Test and deployment logic are duplicated
Large multi-contract systems are hard to manage
Other
Which of these capabilities, if production-ready today, would change how you deploy contracts?
*
Which of these capabilities, if production-ready today, would change how you deploy contracts?
Deployment tracking/state management for forge scripts
Auto-synced frontend artifacts on every deploy
Declarative Diamond / large contract system management
External deployment import (reference already-deployed contracts by address)
Live reload: contracts redeploy automatically on save during dev
Deployment logic that doubles as test fixtures with no duplication
Framework-agnostic deployment library (works with Foundry, Hardhat, or any tool)
Live reload without being locked into a specific contract architecture
Declarative proxy config (dev proxy → mainnet immutable, no code change)
Foundry test integration
Run deployments directly in-browser
None of the above
Other
Open to a follow-up conversation?
*
Open to a follow-up conversation?
A
Yes
B
No
Submit