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