Suggestions for Improving KVM Usability and Developer Experience

Unfortunately, I didn’t pay enough attention to where discussions about the KVM should take place, so most of our interactions with the team happened primarily on Slack. Nevertheless, we’ve compiled some points that might be worth considering for future improvements.

Our team has significant experience but encountered smart contracts for the first time, which led to some challenges early on. It might be helpful to pay more attention to this category of developers who are exploring smart contract coding for the first time.

Suggested Improvements

  1. Contract Response Interface
  • Currently, there is no interface to display the contract response. To view it, one must use Curl and then convert the answer via a hex converter. Since there are interfaces for both invoke and deploy operations, adding an interface for the response would be highly beneficial.
  1. Rust Version Requirements
  • There’s no mention of the required Rust version, which caused confusion. It’s worth noting that the latest version isn’t compatible, so specifying this upfront would save time and frustration.
  1. Key Generation Process
  • The process of key generation was not smooth:
    • It wasn’t clear what BLS is, where to get it, or how to use it.
    • The provided example data didn’t fully match the output we received during the process.
    • A more detailed manual for key generation would be extremely helpful.
    • Additionally, the first generated keys didn’t work in Docker due to formatting issues—specifically, one of the symbols was non-hex and was not accepted by Docker. This required us to regenerate keys from scratch.
  1. OS-Specific Versions
  • It would be great to have versions tailored for other operating systems like macOS or Windows. (Yes, feel free to tease us for this, but it would make adoption easier for many developers.)
  1. Outdated Docker Compose Version
  • The docker-compose.yaml file uses version 3, which is outdated. Docker itself prompts for this version to be removed or updated.

In addition, as active developers, we have already made a significant contribution by improving many proposals and are actively involved in the Klever Slack community. I hope this will also be taken into account during the evaluation process.


These suggestions are based on our team’s experience and feedback during the process. We hope they can contribute to making KVM more user-friendly, especially for developers new to smart contracts.

7 Likes

Great suggestions here!

Enhancing KVM usability and improving the developer experience is crucial for fostering growth within the Klever ecosystem. Streamlined documentation, better tooling, and support for developers will encourage more adoption and innovation. I’d also suggest introducing developer incentive programs or hackathons to engage the community further. Looking forward to seeing how these ideas are implemented!

4 Likes