Juno: My Focus & Path Forward

This article outlines my focus on Juno over the coming months and the problems I am working to solve. How I expect to help drive growth to Juno in my work, and bring more value to all stakeholders.

My Background

Hi, I’m Reece (@Reecepbcups_, https://reece.sh) and I am the Development Lead at Juno Network.

I started in Cosmos in 2021 working to on the Craft Economy project. This was my first job out of University and the task was daunting: Connect a Minecraft server experience to a Cosmos Blockchain to settle in game actions backed by the CRAFT token. Keeping latency (6s blocks), Permissionless Security, and an amazing UX in mind.

Coming in, my entire experience with blockchain so far was just gambling on Roobet with ETH and BTC, and selling it back to coinbase frantically waiting to see the transaction come through. I was so in over my head at the time, imposter syndrome kicking in and wondering “Can I really be a blockchain engineer?” from all the problems I had to brute force to solve.

In the months that followed I was writing a CosmWasm NFT marketplace, middleware REST API, and the minecraft integration plugin. All while managing 3 Java developers, working with the Cloudmos frontend team, and building bots like @CosmosGovNotifs on the side. It was so much fun, but much more difficult than it should have ever been.

What I found out

Learning the Cosmos SDK (especially the infrastructure side) was so hard because it had to be brute forced learned. There was no documentation for the problems I was solving. Better yet, the common things which I needed to do (Ex: airdropping tokens to other chain addresses) had no documentation either. I felt defeated a majority of the time, grabbing any pieces of information I could stick together to try and get it to work.

It took me at least a month writing scripts, trying to figure out how to airdrop…

• find REST APIs to query delegations, then realize its too slow
• figure out I need a ‘database’ of balances and staking
• state sync my own node did not work, gave up
• Found a validator (Nos Nodes ❤) who had some exports
• Write script to stream parse it and perform the business logic
• Export to a shell script to init genesis accounts
• Finally get a working airdrop genesis with all token holders as expected
• Try and figure out how to coordinate a chain launch with genesis & validator transactions.

I was constantly finding myself fighting uphill like this with no documentation and very little available help from the contracted blockchain team.

With this, I have worked to implement documentation, scripts, and automatic daily exports to help aid future airdrops for developers, but it’s still far from complete. By 1000% more than I had when I tried to do this in 2021.

While I would not be as well versed in the Cosmos with out these struggles, other developers coming in will NOT put up with the same level of learning pain as I was willing to endure. While it was a ‘feature’ for me, its a bug to the other 99% of developers out there.

My Role at Juno

I joined Juno as a Software Engineer in November of 2022 under Jake, then officially joined the team in March of 2023 as the Development Lead.

All of my work log is open source and updated daily at https://work.reece.sh. This includes side projects, Juno work, and contributions I put towards other networks in the interchain.

Building

Some things that brings me the most joy are solving problems, creating new products, and automating boring repetitive task. At Juno, I get to do all these things and hop between each at different stages in products life cycle.

With the recently announced Juno Evolution article, I will be stepping in to help improving the performance of Juno, bring CosmWasm based modules to the network, and building better tooling for developers and users alike. Two of these are for scaling Junos future, and CosmWasm modules are a new feature which will help speed up development without having to fork the Cosmos SDK (something we have avoided doing).

I am here to build rapidly to deliver growth and sustainability to the network. I work on behalf of the operators, stakers, network users, and developers. I will not lose sight of this in the bear or bull markets.

Documentation & Onboarding

While building new features on the network for developers is important, it is NOT the most important if no one knows how to use them.

Once we launch the v15 upgrade (faster block times), a large part of my time will go to working on docs.junonetwork.io. This will bring new guides to Juno for anything related to the chain. Our modules, running infrastructure, useful scripts and contracts, as well as a list of must have resources.

For example, where do CosmWasm developers even start? Juno’s documentation should link and guide though this.

Where do Juno developers get information such as an account balances? We need to link to how to query it from Keplr, using the command line, and using the REST API (and cosmos directory).

Developers need examples, and that alone helps a ton with self documentation. While this is seen as “spoon feeding” by more experienced developers, this allows for entry developers to come in and mess around getting their idea to proof of concept quicker. Juno needs more experimentation, more people building cool new things just for fun, then being able to monetize that with FeeShare and other funding mechanism as your application gains transaction.

We need to make onboarding of beginner Rust and Solidity developers easy. This trickles up to more experienced developers by ensuring the basics are all in 1 place with the most common problems all contract developers will eventually run into are solved. We need to make it easy. If a beginner can do it, anyone can.

We need to build it so others can build on us for their users. It does not matter what great chain features we have if no one knows how to use it but the people who implemented it. That is not scalable, and Juno needs to scale.

If we are going to be an incubator chain, we need to have the best documentation and examples of anywhere. Failure to do this and we are nothing more than a chain with a few top performing developers building niche applications for ourselves. This is not an exciting future, and not something I want to see Juno turn into it.

Communication

I am now starting an end of month Developer and Validator call via discord. Our first call will be April 27th at 1600 UTC (11AM Central / Noon Eastern) in the Juno Discord. This will be a time for me to share current updates, plans, and listen for feedback from other teams. I want this to be a time for developers and validators to come and share their technical issues and concerns with Juno. This includes tooling, infrastructure, UX, and documentation you feel we lack and should put focus on.

Infrastructure

Connection Endpoints

Cosmos infrastructure is lacking. Even with more documentation, it is still not scalable in its current form. With this, node operations teams have to drastically limit the number of requests per minute to not go down. This is a terrible user & developer experience when building a new product. It is also costly and some teams are spending upwards of $100,000 USD PER MONTH in server hosting cost for nodes. Unacceptable under today’s ‘light’ user requirements compared to future growth requirements.

Currently a poorly written web application can take down the entire chain. We saw this earlier when an exchange launched with an improper frontend. This hit nodes with the same 5 requests every millisecond with the launch of the website. One single application should NEVER take down all of a network, and rate limiting is not a solution to this.

To solve this I am working on a horizontal scaling solution, Cosmos-Endpoint-Cache. This program allows for multi processed requests, saving commonly accessed data, and allows for a mesh network of providers if nodes go down unexpectedly. With this, providers will be able to drastically reduce their hosting bills and service more with less.

Indexing & Archive data

Cosmos nodes only provides the last 30 days worth of data by default to save space. To get more than this, it requires a special Archive node. Currently these archive nodes are slow, costly, and require a lot of maintenance to set up. A goal of mine is to drastically decrease all 3 of these areas so that anyone can easily run an archive node within a limited budget for a network.

For developers who just want the data to perform analytics, I have written a Cosmos Indexer which indexes all transactions quickly (4.5 hours to index 1.5 years of Juno’s blocks). So instead of 8TB+ (8,000GB) of data storage, it will require just 0.005TB (50GB) of space. With this, a developer can then perform analytics on smart contract usage, sends, and delegations over time with less than 50 lines of code per requirement.

This will double in the future as an RPC frontend to allow for a simulated archive node for usage, while housing many times less of the storage space required. It still has much work to do, but it is an active solution which is being worked on by myself to solve this problem. If you are interested in contributing, please reach out.

Competition

Juno does not have competition. Products which others say are Juno’s competition have typically not launched yet. Juno is an incubator chain and we celebrate other chains which are coming up with permissionless CosmWasm. The whole point of the interchain is to connect with these new chains to allow for unique business models, use cases, and applications to leverage eachs strong suits.

Developers have choice to build wherever they want, and that place has been and will continue to be Juno even with other chains launching. To date, Juno has done 14.54 million contract executes. That is 25,000+ per day since launch (Oct 1, 2021 -> Apr 23rd 2023)

Vesting

Just like I am open with my work log, I find it important to be open with my finances for Juno network’s token holders. I was recently was awarded a 400,000 $JUNO vesting contract from the Core-1 team on behalf of the work I have done for the network and will continue to do (~$300k USD vested over 3 years linearly).

Before this & joining Juno in my own personal wallets and accounts, I am down ~$40,000 USD on my Juno holdings.

Given the current market conditions of Juno, I do not find it morally acceptable to profit off token holders with selling pressure of this amount as it unlocks. For this reason, I will not be selling the base capital until Juno is in a significantly better adoption and financial situation. Realistically I would like to not touch it at all until the end of the 3 year term.

I view this vested position as $0 or tens millions in the coming years. If I do not and can not drive value, then I do not expect value to be returned to me. This stance aligns me with token holders and requires me to not just work, but grow the network for the benefit of all. This is a daunting challenge, but something I am up for.

Final Thoughts

I strive to move quickly, solve problems, and bring developer and user adoption Juno and CosmWasm.

Surviving a difficult bear market only makes Juno stronger in the next bull run. There is no better position Juno could be in than having a hard time and a community who sees the possibilities despite current market conditions. It forces us to work on solving what really matters, being lean, and driving token usage. Growth is what matters, both personally speaking and as a network.

I love what I do, and I am glad I get to call Juno my home. Thank you to the Core-1 team for allowing me this position, and for the $JUNO stakers and network users for letting me develop for you.

We are just getting started.