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
Hardhat Ignition
D
custom scripts
E
MUD
F
forge scripts
G
other
Which of these are part of your current setup?
*
Which of these are part of your current setup?
Hardhat Ignition
Fully onchain game requirements
I am actively evaluating alternatives
Hardhat 2
Upgradeable contracts / proxies
Foundry / forge scripts
Local-first or offline development matters
Hardhat 3
Proxy for dev and immutable on mainnet
hardhat-deploy v1
MUD framework
hardhat-deploy v2 / rocketh
Multi-contract system
Frontend needs deployment data synced automatically
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?
Named accounts / role-based deployment configuration
Mud world contract support
Deploy tags for partial/selective deployments
Live reload (auto-redeploy on contract changes during dev)
Flexibility for deployments
Ability to execute deployment in browser
Local simulation / local-first workflow
Large Contract System Handling (Diamond, MUD world, router, ...)
Repeatability across environments
Contract verification
independence of framework (foundry, hardhat) upgrades
Recovering from interrupted deployments
Deterministic deployments
Reusing deployment logic in tests
Speed
Faster iteration during development
Deployment tracking
Full TypeScript type safety for deployments
Stability of api
Frontend integration / exporting deployment data
Declarative Proxy Deployment (no manual upgrade specification)
Simplicity
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 more flexibility than the current model offers
I tried it and it did not feel ready for my use case
My current setup already works well enough
I need stronger test and deployment reuse
I need better upgrade / proxy support
Migration cost is too high
I need better support for complex multi-contract systems (Diamonds, MUD world...)
I have not spent enough time evaluating it yet
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?
MUD framework
forge scripts
Moving from hardhat-deploy v1 to v2
custom deployment scripts
Hardhat Ignition
no serious investigation recently
Other
What frustrates you most about your current setup?
*
What frustrates you most about your current setup?
Upgrades / proxies are awkward
Docs / examples are not good enough
Too much boilerplate
Large multi-contract systems are hard to manage
Migration cost is too high
Deployment state is brittle or gets corrupted
Locked into a specific framework's contract architecture
Local development experience is weak
Hard to manage multiple signers/roles across environments
Test and deployment logic are duplicated
Frontend integration is painful
Tooling feels incomplete or unstable
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?
Auto-synced frontend artifacts on every deploy
Declarative proxy config (dev proxy → mainnet immutable, no code change)
Foundry test integration
Live reload without being locked into a specific contract architecture
Run deployments directly in-browser
Framework-agnostic deployment library (works with Foundry, Hardhat, or any tool)
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 tracking/state management for forge scripts
Deployment logic that doubles as test fixtures with no duplication
None of the above
Other
Open to a follow-up conversation?
*
Open to a follow-up conversation?
A
Yes
B
No
Submit