# Survey Results

## 1. How long have you developed Smart Contracts?

| Answer Choices | Responses | Count |
| --- | --- | --- |
| No experience | 7.8% | 4 |
| < 1 year | 31.4% | 16 |
| 1 - 3 years | 49% | 25 |
| > 3 years | 11.8% | 6 |

## 2. What Smart Contract languages do you use?

| Answer Choices | % of Respondents | % of Responses | Count |
| --- | --- | --- | --- |
| ink! | 74.5% | 42.2% | 38 |
| Solidity | 74.5% | 42.2% | 38 |
| CosmWasm | 7.8% | 4.4% | 4 |
| Other | 9.8% | 5.6% | 5 |
| Cairo | 3.9% | 2.2% | 2 |
| Move | 2% | 1.1% | 1 |
| Vyper | 2% | 1.1% | 1 |
| Yul | 2% | 1.1% | 1 |

Other: Soroban, Near and PyTeal

## 3. Do you want to deploy Smart Contracts in the Polkadot ecosystem?

| Answer Choices | Responses | Count |
| --- | --- | --- |
| I have already | 39.2% | 20 |
| I want to | 51% | 26 |
| I don't want to | 9.8% | 5 |

## 4. What are the biggest challenges in deploying a Smart Contract in the Polkadot Ecosystem?

### Ecosystem (28%):

1. Lack of liquidity, and users
2. Lack of traction
3. lack of support on the relay chain
4. Lack of adoption
5. no chain I can host them.
6. A place to display example grade project
7. Not too many parachain support ink!.
8. Understanding where to deploy it
9. unclear developer journey, where will my contracts live? In what chain?
10. Figuring out where to deploy, getting tokens
11. Not knowing in which chain to deploy it
12. Where do I deploy it? There is no Polkadot smart contact chain!
13. Where to deploy
14. Getting non-DOT tokens can be tedious sometimes, especially in the US.
15. None as long as the it is EVM chain
16. Hard to decide where to deploy it, still can't benefit with the whole Polkadot potential with Smart Contracts
17. Choosing a suitable blockchain and not having access to much liquidity.

### Tooling (21%):

1. Not too many parachain support ink!. Tooling is immature.
2. The lack of block explorers for test chains.
3. Tooling for XCM, easy global wallet integration (EVM+substrate)
4. Lack of tooling for ink! Contract verification not implemented.
5. Tooling around the whole process.
6. Much fragments in my structure but not simple solution to advance
7. lots of buttons and functions on polkadot UI, etc
8. Tooling is immature.
9. ink seems abandoned, suboptimal DX
10. Lack of infrastructure
11. Setting up the infrastructure to develop them, and testing them offline using Substrate contract node for Windows users.
12. Infrastructure is much less matured than EVM (Explorer, wallet, indexer, oracle, etc)
13. Getting visibility/usage of my dApp.

### Complexity / Fragmentation (13%):

1. polychromatic weight, frontier being heavy, acala EVM being experimental
2. Difficult technology
3. Cross-contract
4. pallet first mentality
5. Deploying smart contracts interoperable with different parachains
6. Much fragments in my structure but not simple solution to advance
7. One is that there’s so much going on (different chains, lots of buttons and functions on polkadot UI, etc) that it’s easy to become overwhelmed.
8. Testing whether my code works as expected in a multichain approach

### Documentation (13%):

1. Examples, tutorials in Spanish, examples project finish, more discussion in other languages.
2. better documentation
3. Lack of decent quick start templates for full-stack dApps. Not really an issue anymore as I am using inkathon these days.
4. Lack of example production-grade projects.
5. Lack of documentation surrounding interactions with unique core runtime features
6. learn that stuff. Everything is scared across and it took a bit of while to put things together. Mentally and literally.
7. ink is not widely used as solidity and examples and community are too small
8. How should I deploy? Setting up a script in Polkadot.js is unclear from the documentation.

### Standards / Libraries (11%):

1. Standards
2. Breaking changes.
3. Security. Secure/verified/audited building blocks
4. Libraries are constantly evolving
5. Lack of clear standards. No confidence in PSP, especially after Brushfam drama + their implementations are too complex. Need 'no frills' core implementations, possibly owned by parity, and for parachains to adopt and use these.
6. Lack of standards or proposal process that's well maintained like EIPs on Ethereum. This single-handedly creates the biggest obstacle.
7. Security. Secure/verified/audited building blocks

### ink! / Rust (8%):

1. Rust compiler
2. Environment setup, in particular matching rust versions with dependencies.
3. Lack of mulit-file in ink!
4. Ink! code is difficult to maintain in a single file and it's too complex to split. (impossible)
5. ink! is not good. Solidity is the most mainstream language, but all the Polkadot-specific tooling around Moonbeam is complex because for example XCM is really not easy to use.

### High costs (5%):

1. Weight cost
2. Transaction fee
3. Cost for TXs vs Solidity

## 5. How would you rate your satisfaction with the current Smart Contract deployment options within Polkadot?

Average = 5.73

| Scale | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Responses | 0% | 3.9% | 13.7% | 7.8% | 15.7% | 23.5% | 17.6% | 13.7% | 0% | 3.9% |
| Count | 0 | 2 | 7 | 4 | 8 | 12 | 9 | 7 | 0 | 2 |

## 6. On the positive side, what do the current Smart Contract deployment options within Polkadot do well?

### ink! / Substrate / rust (41%):

1. Relatively easy onboarding for Rust Engineers
2. Easy to understand language. Less pitfalls than solidity (apparently)
3. WASM
4. Rust
5. Rust
6. the technology looks powerful and with huge potential.
7. They are straightforward once you are able to get them running.
8. Support on Stack Exchange
9. it’s relatively easy to do so
10. Developer environment seemed more advanced than I thought it would be, and the ink interface while not perfect was quite nice
11. Pallets make a lot of stuff easier.
12. honestly it's really down to the fact that they're all using rust. Also ink! is a well-developed library.
13. Writing in Rust is acceptable, but it has been demonstrated that there are disadvantages, as outlined here: https://blog.inkscope.xyz/supply-chain-attack-for-ink-smart-contracts
14. ink is nice
15. Using ink! is really nice with Rust
16. Ink enables the use of rust libraries not available in Solidity
17. Precompiles and chain-extensions for pallet-assets is nice.
18. ink! is great can easily move into a pallet development from ink!.

### Ecosystem (27%):

1. EVM-based chain just work ( Astar, Moonbeam )
2. Aleph Zero provides a lot of support for ink! contract developers -- via docs, and telegram, discord support.
3. Moonbeam has pretty good compatibility with other EVM-based chains
4. Variety of chains to deploy, possibility to create interactions between parachains, EVM compatibility + precompiles of Moonbeam
5. Cross-chain interoperability through Phala's Phat Contracts with the ability to upload indeterministic code to run in their ink! Contracts. Another is Astar and AlephZero have done great work to push the ecosystem forward.
6. EVM contracts follow the same deployment rules as on other non-Polkadot chains
7. I think Moonbeam is doing a great job but they're Solidity/EVM and are usually thought of as separate from Polkadot. I do not think they are the solution to "deploy a contract on Polkadot".
8. Astar's dApp staking is an attractive option to deploy.
9. There are several chains offering unique features with regards to smart contract features: phala, t3rn, aleph zero. In addition, they organise hackathons which is important
10. They work! Exposing different options from the same UI is very friendly, though not every dev would need to deploy in several chains.
11. Moonbeam
12. Opens up innovation from teams focusing on how to provide a smart contract chain as a competitive service for devs.

### Tooling (23%):

1. Fast, easy to set up
2. Provides agile deployments with simple UIs
3. Contracts UI is great
4. Easy-to-use CLI tooling
5. Contracts UI works fine and user-friendly. E2E tests and deploying on the local Contracts node allow speeding up the development.
6. Tools like drink! help to slowly bridge the gap between solidity and ink!
7. chainide
8. Contracts UI
9. substrate contracts node and the CLI works well, after I got it ^^
10. Contracts chain in Rococo and Contracts UI make testing easy

### Documentation (9%):

1. Tutorials, Easy to code
2. ink has some nice examples and a deployment portal
3. Docs are good but they should be better.
4. Good documentation

## 7. On the negative side, what are the current Smart Contract deployment options within Polkadot lacking?

### Tooling + Documentation (34%):

1. Cumbersome events, not a lot of tooling
2. Tooling, Subscan support. Contract verification.
3. More tooling (type VIEM) & docs to integrate better XCM
4. Tooling. There are lots of issues with compatibility.
5. Tooling that is similar to EVM dev experience. Most tools end up getting developed by constrained teams so the ability to maintain a blockchain along with creating tools makes the DevX terrible
6. Lots of ways to deploy, but none work well. Also many ways to do it. Keep honest talk: deployment is still hard.
7. CLI instead of contracts UI
8. Easy/simple UI where the contract is validated and users can (with no extra manipulation) use the contract methods.
9. some toolings
10. Documentation is lacking, especially for more niche features. The UI side of things is a mess, outdated documentation, requires a lot of reading code in other projects. Also, I don't want to focus on UI; useink is a step forward. Unclear how to deploy.
11. Still behind Ethereum in terms of tooling for deployment, and not a lot of examples on how to interact with it with a frontend tool
12. Would be nice to see costs beforehand or having a dry-run of what deploying your contract in that platform would look like.
13. tooling is lacking for non evm chains.
14. More examples, step-by-step guides, and an easier way to get answers about complex issues

### Ecosystem (29%):

1. Smart Contract Hub, limited block explorer functionality
2. Proper focus on ink! Better docs, tutorials, DX and projects in the ecosystem using it.
3. No forkable projects
4. Lack of a system-chain that supports pallet-contracts
5. Adoption, funding, project ideas
6. Lack of support on the relay chain, have to go to the parachains and consume their parachain tokens
7. Ghost chains?
8. DOT payment
9. Deployment with DOT
10. We need a Polkadot Smart Contract Chain! Duh
11. No easy way in, support, focus on ink!
12. Anything but Moonbeam (anything that is not fully Ethereum compatible and has native ECDSA accounts like Moonbeam)There seems to be no single place for me to deploy where everyone is tinkering. The dev base and user base is fragmented across chain X, Y and Z.

### Standards / Libraries (15%):

1. stability of ink! and pallet contracts
2. Library to support ink! smart contract
3. stability of ink! and pallet contracts.
4. Standardization still early
5. Merging the libraries Ink! and OpenBrush to create a standard
6. Unity and direction in standards for basic needs. Nobody knows what the right way to make an ERC20 or ERC721 equivalent, so don't bother. Ink! has their own example implementations, Brusham/PSP is available but with massive risk - it's not clear. Nobody wants to risk developing on a standard that will not be supported/adopted, so they just go to EVM where that is guaranteed.

### Primitives (15%):

1. Options to interact with the runtime from within ink! contracts are not mature.
2. Interop with eth SC
3. Lack of ability to easily interact with runtimes
4. Moving items outside of the contracts pallet can be difficult. Communication through XCMP would greatly improve this process.
5. The use of precompiles to interact with pallets that access Polkadot features like interoperability
6. Options to interact with the runtime from within ink! contracts are not mature.

### Developer Experience (7%):

1. Getting the developer environment completely set up correctly with versions of Rust and versions of packages was more of a hassle than I wished it was. Took a few days
2. learn it and contract combine with frontend. It's a mess for a newcomer and even for me still a bit^^'
3. The amount of steps needed to set up everything

## 8. What would improve the Smart Contract developer experience in the Polkadot ecosystem?

| Category | % Respondents | % Responses | Total |
| --- | --- | --- | --- |
| Tooling | 65.3% | 16.6% | 32 |
| Cross-Chain Interactions | 59.2% | 15% | 29 |
| Robust Documentation | 55.1% | 14% | 27 |
| Ease of Development | 53.1% | 13.5% | 26 |
| Incentives and Support for Innovation | 36.7% | 9.3% | 18 |
| Innovative Pallets and Primitives | 32.7% | 8.3% | 16 |
| Community Support and Collaboration | 32.7% | 8.3% | 16 |
| Scalability and Performance | 24.5% | 6.2% | 12 |
| Security Measures | 18.4% | 4.7% | 9 |
| Other | 16.3% | 4.1% | 8 |

other:

- migration guides from Solidity
- Focus on stability -- less breaking changes in pallet contracts and its dependencies.
- Clear standards & best practise for fundamentals (tokens, defi, nfts, etc). And for somehow contract-pallet providers to align on this.
- relay chain support
- 30 hours tutorial. From 0 to hero. No small chunking of seperate subject. Video format. ^^
- A place to deploy a contract on Polkadot - a Polkadot-native smart contract chain.
- Frontend templates
- Workflows for typical cross chain interactions ™️. What’s also lacking is the lack of thorough auditing. What’s also lacking is standards and audited implementations of them.

## 9. How important is it to be able to migrate your Smart Contract solution to its own dedicated chain (for scaling)?

Average = 5.16

| Scale | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Responses | 17.6% | 2% | 7.8% | 9.8% | 21.6% | 9.8% | 7.8% | 9.8% | 5.9% | 7.8% |
| Count | 9 | 1 | 4 | 5 | 11 | 5 | 4 | 5 | 3 | 4 |

## 10. Would you deploy a Smart Contract on a platform that allows deployment in the native network token (e.g. DOT/KSM)?

Average = 3.71

| Scale | 1 | 2 | 3 | 4 | 5 |
| --- | --- | --- | --- | --- | --- |
| Responses | 15.7% | 7.8% | 13.7% | 15.7% | 47.1% |
| Count | 8 | 4 | 7 | 8 | 24 |

## 11. What would your dream Smart Contract platform look like?

1. Fast, cheap, universal
2. Yours
3. Full Ethereum compatible, easy cross-chain tools and access to liquidity
4. One where my deployed smart contract is limited in any way by the underlying infrastructure, not as a dev I have to take care about it.
5. Easy to build SC to interact with runtime code: NFTs, Staking... Easy to use XCM and ETH Compatibility
6. Scalable, cheap to interact with, and full of liquidity.
7. Providing the docs, examples, building blocks to easily learn smart contract development and then the resources to build solid dapps and innovate
8. Excellent tooling and documentation to make it super easy to get started. I also want more focus than just the smart contract, the full-stack side of things is important for my dApp.
9. Netlify/Heroku for Smart Contracts with AWS-like features.
10. Hardhat
11. Osmosis, one-click you can do everything. Wallet like Metamask, only one address, hide others' addresses to the ecosystem, more ease to users
12. "Platform" to deploy on? -- what really matters is whether the chain is active, has users, has TVL.
13. Audited and stable libraries with the possibility to use any amazing powerful pallets
14. Like FRAME, but does not need to convince OpenGov to add it to the runtime
15. Smart contract platform where interoperability and cross-chain are a first-class citizen and not a challenge
16. Quick, simple and amiable. The a button opens all, b resets default and lots configurations
17. An IDE with AI tailored for blockchain development.
18. Smart Contracts on the Relay Chain
19. Easy integration of native tokens, easy integration with existing infrastructure (marketplaces, exchanges, etc.). Atm building in ink leaves you on a desert island. Also, a dream would be native non-pseudo RNG via chain-extensions!
20. Deploy once with the ability to interop with any chain anywhere. No limitations on EVM, substrate, cosmwasm, move, etc. And just build your web3 stack based on developers' requirements and constraints
21. Usable, maintainable, easy to comprehend, and shareable
22. Anything where I'm able to trace line by line where an issue went wrong. INCLUDING CORE RUNTIME
23. Lots of working examples, lots of templates, lack of hate of the community.
24. ink! is already pretty nice, no need to reinvent the wheel every year
25. Remix + Community Support
26. An intuitive space with native tokens
27. Easy to deploy, cheap, without constant breaking changes and needed maintenance from the blockchain perspective
28. Easy onboarding, oracles, DEXes, useful primitives, share of rewards, dApp promotion/leaderboard
29. A platform where I could easily read the source code of any contract and read the storage items like in a classic DB
30. Easy and cross-chain
31. Hello I'm Frank. I want to develop a Smart Contract on ...ehh.. Interlay. My contract should be called a PiggyBank. It should hold native tokens. There is a function called withdraw. The deployer is the owner of the contract. If the deployer calls withdraw all tokens from the smart Contract gets transferred. Write me a step-by-step guide of how to make this happen. Start with install substrate node and end with call contract with drawn. I wanna just paste commands in my terminal.
32. Free

## 12. Add anything you like to share about Smart Contracts on Polkadot

1. There needs to be better narratives around using smart contracts to tinker ideas with. Then if necessary got to parachain. But there also needs to be narratives and hard numbers around why the migration is needed. Beyond tinkering, users should be able to scale businesses on Polkadot using smart contracts that maximise the utility of other non smart contract onchain services powered by Polkadot and other chains. And this probably won’t happen if not for standards and opinionated workflows for developers to easily grasp and tinker with.
2. EVM and wasm still feel two different worlds within the same ecosystem. It might look like Moonbeam is not competing against Astar, for instance, but the truth is that purestake has addressed the market in a very smart way. I wonder how would they address scaling without making their users default to writing a runtime and jump in the Tanssi waggon
3. We need more education around Smart Contracts on Polkadot
4. ink! has a lot of potential, we need a platform to enable developers to learn, experiment and innovate with ink!
5. We need to make it easy for devs from other ecosystems to deploy contracts on Polkadot.
6. Overall great, needs adoption
7. Examples whit UX, in Spanish too,
8. ink! is awesome, we need more people involved!
9. Setup ORUs on Polkadot.
10. After experimenting/building with ink for 2 years I ended up giving up. Great tech, but surrounding tech was too immature and changed too often. Spent so much time refactoring/upgrading, the churn became too much. We really need basic infrastructure. Uniswap style exchange for ink! contracts, with a token standard that is clear and obvious.
11. Ink! Is expensive, we need to put effort into ink! Standards, reduce barriers to entry
12. Too much hate in the community.
13. We need more developers looking at it.
14. this doesn't help much to be motivated to start with Smart Contracts on Polkadot: https://wiki.polkadot.network/docs/build-smart-contracts#building-a-smart-contract
15. wen PolkaVM?
16. We still need a video^^