Co-working and AMA with Bilbo Baggins, Solid Snake, Mangochutney, Chopstick Sensei, and notjoshc

Since the “Expanded & Finalized L1 Task Force Spending Prop for Q2 2023 [v3]” proposal (Prop 11463) has been put up for vote we’ve received a lot of requests from the community to host an AMA and give the community a chance to become more familiar with our team so that they can make more informed decisions on how to vote. We’ve thought hard about how to do best this in a manner that respects our team’s desire to remain doxxed, while also giving the community the chance to ask the questions so that they can get the answers they deserve. This Co-working and AMA thread on Agora is a shot at us trying to do that. It’s a format that hasn’t been done before, so this is just as much an experiment as it is an AMA, and I expect we’ll adjust and adapt how we run this as we see how reception to this kind of format is. If this format ends up being particularly successful it may end up being a format that we adopt on a more regular basis so that the community can be involved in the development of LUNC in a more intimate manner then before, and learn more exactly about how this blockchain works so that they can make decisions about the future of their blockchain from a position of knowledge and confidence instead of fear and uncertainty.

For our first run the format we’ll be using in this thread is simple. As a team, we’re going to be conducting our normal daily business as we prepare for the possibility of contributing to the L1 development of the chain, in the open, with discussion between team members happening in this Agora thread instead of where we’d usually be interacting. The community will be able to act as a fly on the wall and pipe in with questions / comments whenever they want in this Agora thread, and the team will answer those questions as we’re going about our day to day business of preparing for the possibility of the proposal passing and us working on the chain. We’re hoping to achieve a large amount of transparency and willingness to collaborate with the community that in our opinion has been missing for quite some time now. Our hope is that we cover a lot of topics today, and that a lot of good, respectful, and productive discussion is had.

To speak personally for a moment, I’ve been in this community since the crash. I’ve been there for the highs and the lows, and I’ve had to endure the pain of seeing the community’s trust get taken advantage of a multitude of times. So we’re going a different way. We don’t want you to trust us. We want you to trust our actions. No words, just undeniable proof. And the community can decide for itself accordingly. The community’s trust has been violated enough, and the pain the community from those violations of trust is palpable. You can feel it in the air. You can feel it in the interactions people have with each other. The community has been hurt by people they have placed their trust in too many times. People have been attacking each other left and right for months now, and it seems like we have lost sight on why we all came to this chain in the first place after the crash. We aren’t here to fight over money in the community pool. We aren’t here to keep participating in power struggles over a chain that is slowly stagnating either. We’re here to try and right a wrong. We’re here to try and fix a chain that deserves a second chance. We’re here to witness a phoenix be reborn from the ashes of what happened almost a year ago in May. We’re here to try and give the community something it hasn’t had in a long time: hope.

With all that said, let’s get started.

@solidsnake how are things going with your investigation of the 5% minimum commission changes that Ed did for the passing of Prop 11322? I queued you up on some issues with the implementation that I found during a quick code review, and just want to know if you’ve found any other issues since then.
@chopstick.sensei how has your investigation into Terra Operator been? I saw some potential high level issues when I took a cursory glance, and it’d be good to look deeper into it to see how it’s all put together, especially if there’s a possible adoption path for this to be used beyond just chaos monkey simulations in a testnet. We want to also hedge against if validators independently decide to adopt this software for their own nodes and unintentionally introduce risks or vulnerabilities into their own infrastructure due to the additional layers of complexity that are added here via it being a Kubernetes operator (Kubernetes is very useful of course, we just need to be careful of any possible footguns here and avoid them before they happen because of the extra added complexity) - it’d also be good to get some context from Vinh on their intent / progress with Terra Operator and how those align in real world practice.
@mangochutney how are things looking with your investigation of the Oracle Feeder changes that the L1 JTF did? I’ve heard mention from A.E. and seen talk in the validator discord that there’s some issues with running it in practice, so it’d be good for us to take a deeper look at that and see what’s going on there.
@notjoshc how have things been progressing with your exploration of the Terra Classic codebase?


Will parity with v2 be the first priority with your team


What other ideas or future improvements do you want to implement?


Hi @Bilbo !

any chance you can post some kind of CV summary (names removed) of the key people.
looking for dev experience, and cosmos-blockchain dev experience in particular




Hey @Bilbo, as you identified there is indeed some logic flaws with the code that make it all but guaranteed that the code will fail to force every validator’s commission to be at a minimum 5% if this code was run as a software upgrade. As you already identified, if we look here: Comparing main...min-commission · classic-terra/core · GitHub we can see that the stakingKeeper.UpdateValidatorCommissionstakingKeeper.UpdateValidatorCommission function when called in the Cosmos SDK also calls a ValidateNewRate function here: cosmos-sdk/commission.go at v0.44.6 · classic-terra/cosmos-sdk · GitHub that will fail if the following checks fail:

switch {
	case blockTime.Sub(c.UpdateTime).Hours() < 24:
		// new rate cannot be changed more than once within 24 hours
		return ErrCommissionUpdateTime

	case newRate.IsNegative():
		// new rate cannot be negative
		return ErrCommissionNegative

	case newRate.GT(c.MaxRate):
		// new rate cannot be greater than the max rate
		return ErrCommissionGTMaxRate

	case newRate.Sub(c.Rate).GT(c.MaxChangeRate):
		// new rate % points change cannot be greater than the max change rate
		return ErrCommissionGTMaxChangeRate

This logic as you already identified ensures that the following validators would fail to have their commissions updated in a software upgrade, due to their maximum change rate being lesser then the delta of the change from their current commission to 5%:

0% Autism Staking
1% Max Fee
Bit Cat
Crypto Genesis
LUX Blockchain Validators
TCB @ THORmaximalist
tera bitz

In addition to that, we’d also have to be especially mindful of this code block here:

case blockTime.Sub(c.UpdateTime).Hours() < 24:
		// new rate cannot be changed more than once within 24 hours
		return ErrCommissionUpdateTime

As if any validators have changed their commissions 24 hours before the software upgrade is done, that could also cause the upgrade to fail. This is in addition to the already accounted for possible failure case outlined here where we can’t set a rate that’s greater then their maximum commission rate.

case newRate.GT(c.MaxRate):
		// new rate cannot be greater than the max rate
		return ErrCommissionGTMaxRate

The smartest way to go about testing this upgrade and ensuring we have the desired results is to get the testnet set up with validators, and simulate the possible states a validator’s commission can be in, since there’s only so many possible variables here and they aren’t so great in number that we can’t just test this ourselves in the testnet and ensure that the desired end result is as we expect. Awareness of these flaws in the current implementation also makes it so that potentially malicious validators inside or outside of the active set can’t take advantage of these flaws to ensure they have a 0% commission.

I can speak to this for Bilbo. Parity is absolutely a priority for our team, but in order to ensure we can have a successful parity we need to also ensure correctness of the upgrade. The best path forward for us to do that is to get a testnet setup with actual validators running the testnet. That would be ideal i our opinion, because then we can test the upgrades in real world settings but without the real world stakes (loss of money / funds). There’s also research the L1 JTF says they have done in terms of impact assessments for the upgrade (particularly around WASM) that we would like to see revealed to the community, as what is in those impact assessments are of particular importance and should be shared with the community so the community can make an informed decision.

We’ve been looking deeply at how to really fix the swap mechanism, as we already know that the $1 LUNC === 1 USTC algorithm is prone to hyperinflation risk, so just achieving repeg isn’t enough. We need to also come up with mechanisms to keep the peg as well. Some ideas we have around that involve:

  • USTC Staking
  • Alliance modules to attract new liquidity on chain
  • More that Bilbo won’t let me tell the community about yet since they aren’t fully conceptualized and we don’t know if they’ll work :slight_smile:

Those future ideas / improvements aside, it’s clear to us that there’s not going to be one golden solution, but a bunch of smaller, simpler solutions that can all be composed together to solve the complex problem that we’re dealing with here. The community has also come forth with good ideas to help solve specific facets of the complex problem we’re dealing with here as well, so we don’t view this as us dictating solutions to the community without any back and forth either. We very much view this as a collaborative effort with the community. What matters most is that we get headed in the right direction we’re going, and of course it goes without saying that before any of these ideas / improvements can be implemented we need to achieve parity first. Parity isn’t the end. It’s the start.


Hey @petes-fan-club - thanks for the question. Here’s the CVs as requested.

Bilbo Baggins: Senior Software Engineer & Systems Architect


Founder, Undisclosed Company

  • Created a distributed point of sale system for a franchise of businesses written in Elixir and Vue.js.
  • Created a real time location monitoring and scheduling system for employees of a remote based business written in Elixir and React.
  • Created a two sided marketplace for skilled workers for both iOS and Android written in React Native.
  • Contributed to the design and development of a real time f-raud analysis and detection platform written in Golang and React.
  • Contributed to the development and maintenance of a building inspection platform’s website and iOS / Android apps written in Ionic.

Senior Software Engineer & Systems Architect, Crypto Company

  • Played a key role in backend with Golang and frontend implementation with React for Initial Coin Offering.
  • Contributed to development of crypto trading front-end / backend integrated with multiple trading APIs written in Javascript and Golang.
  • Contributed to implementation of fiat payment processor onramps and offramps for various payment APIs written in Javascript and Golang.
  • Contributed to development, testing, and deployment of Solidity smart contracts for the Ethereum blockchain.
  • Contributed to design and development of iOS and Android apps written in Swift and Java, respectively.

Software Engineer, Automation Company

  • Contributed to the design and development of remote device management front-ends written in Vue.js.
  • Contributed to the development of a micro-service oriented API architecture written in Rust.
  • Contributed to the design and development of secure third party authentication and integration infrastructure written in Rust.
  • Contributed to the implementation of CI / CD pipelines to manage Docker / Kubernetes based deployments across multiple environments.
  • Contributed to the implementation of progressive web-apps that targeted desktop, iOS, Android, and other devices from a single codebase.

Skills and Interests


  • Proficient in Golang, Elixir / Erlang, Solidity, Javascript, Python, Rust, Haskell, Swift, Java / Kotlin, CI / CD.
  • Experienced in CI / CD and dev-ops solutions like Kubernetes, Docker, and Podman.
  • Experienced in distributed architecture design and fault tolerant systems design.
  • Experienced in cross-platform mobile app development frameworks like React Native, Ionic, and Cordova.
  • Experienced in full stack development across a variety of frameworks like React, Svelte, Vue.js / Nuxt.js, Django, and more.
  • Experienced in game design and development, with a particular interest in entity component systems based architectures via Bevy and Rust.
  • Experienced in smart contract development, deployment and management for Ethereum and Cosmos based networks.
  • Experienced in running and maintaing validator nodes for blockchains in the Cosmos network.


  • Everything crypto, blockchain, defi, degov, and finance / investing / trading related.
  • Machine learning and running self managed nodes to further optimize creation and curation of training data and models.
  • 3D printing and automation of 3D printing, be it filament or resin based. Also interested in robotics as an offshoot of 3D printing.
  • Learning, and solving really hard problems.
  • Video games, movies, collecting Time magazines, and writing.

Solid Snake, Senior Systems Architect

Previous Experience

Undisclosed Commpany, Lead Systems Architect

  • Built horizontally scalable architecture for two sided marketplace in Golang.
  • Built fault tolerant double ledger accounting systems via utilization of event sourcing architecture in Elixir.
  • Built robust and scalable web crawling infrastructure utilizing headless Chrome, Docker, and Kubernetes.
  • Built scalable search infrastructure utilizing Elastic Search, Docker, and Kubernetes.
  • Built robust internal data monitoring infrastructure via utilization of Prometheus and Grafana.

Undisclosed Commpany, Senior Software Engineer

  • Built multi-tenant intake and reporting system in Javascript that was sold to customers as a platform as a service.
  • Built geolocation based realtime monitoring infrastructure for remote locations in Rust.
  • Built CI / CD workflows to optimize software deployments for multiple environments and targets.
  • Built horizontally scalable fault tolerant file upload infrastructure in Elixir.
  • Built custom multiplexed realtime websockets client in Javascript.

Undisclosed Commpany, Software Engineer

  • Built realtime chat infrastructure in Golang.
  • Built horizontally scalable authentication infrastructure in Golang.
  • Built internal CLI to speed up and optimize business workflows in Golang.
  • Built iOS and Android apps optimized to display rich form media such as images, videos, and realtime video streams.
  • Built component based library and style guide for multiple front-end websites in React.

Skills, Interests

  • Skills: HTML, CSS, Javascript, Golang, Swift (iOS / OSX Apps), Java / Kotlin (Android Apps), Rust, Elixir / Erlang, Python, POSIX
  • Interests: Reading, Movies, Hiking, Cooking, Hydroponics, Homesteading, Vanlife, Exploring

Chopstick Sensei | Senior Software Engineer

Work Experience

Delivery Service, Lead Developer

  • Developed and maintained an e-commerce and delivery platform with React
  • Implemented robust distributed backend micro-services using Go and Rust
  • Designed and implemented CI / CD workflows for automated deployments
  • Created responsive mobile applications for drivers
  • Implemented Front Ends for major clients

Automotive Company, Full Stack Developer

  • Developed React components for public facing websites
  • Implemented business-critical API endpoints using Go
  • Deployed horizontally scalable live search APIs

Financial Institution, Technical Consultant

  • Developed high-performance automations
  • Implemented front-ends using React Native
  • Built internal APIs using Python

Skills & Interests

Skills: Go; Node; React; React Native; Redux; Solidity; Ruby; Rails; Python; Elixir; Erlang; Django; Bootstrap; Tailwind; PHP; Laravel; C#
Interests: Crypto; Gaming; Collectible Card Games; Game Development; Pizza

mangochutney - Senior Software Engineer

Work History

Senior Software Engineer, Undisclosed Company

  • Design, develop, and maintain microservices and APIs using Golang.
  • Create smart contracts using Solidity for the Ethereum blockchain.
  • Develop native iOS apps using Swift.
  • Implement high-performance and secure systems using Rust.
  • Utilize AWS and GCP for deployment of company infrastucture.

Software Developer, Undisclosed Company

  • Built web applications using Python frameworks like Flask.
  • Built and maintained APIs using Django.
  • Implemented automated testing and continuous integration and delivery (CI/CD) pipelines using Jenkins and GitLab.

Software Developer, Undisclosed Company

  • Contributed to the development of an iOS app using Swift.
  • Collaborated with senior developers to implement microservices using Golang.
  • Implement web applications using Javascript frameworks like React.

Skill Summary

  • Proficient in Python, Golang, Solidity, Rust, and Swift programming languages.
  • Experienced in smart contract development using Solidity on the Ethereum blockchain.
  • Experienced in cloud computing platforms such as AWS and Google Cloud.
  • Experienced in building microservices with Golang and Rust.
  • Experienced in building native iOS apps using Swift.

notjoshc - Senior Software Engineer

Work Experience

Senior Software Engineer, Undisclosed Company

  • Contributed to completing various on-going company projects using C++, Matlab, and React.

Software Architect Engineer, Undisclosed Company

  • Setup and maintained 1/254 Nucypher cryptography nodes worldwide, supporting the Nucypher network.
  • Designed, created, and maintained new C++ CUDA video upscaling desktop software for distributed multi-node environments (online and local).
  • Designed, created, and maintained Vue.js/Nuxt.js websites for company’s products and online store.
  • Designed, created, and maintained Flutter Android/iOS website browsing app.
  • Researched Ethereum and Polygon blockchain for future integration into the C++ CUDA video upscaling project.
  • Designed, created, and maintained Flutter and C++ Android/iOS price tracking app, with Python and C++ webscraping backend and datbase.
  • Designed, created, and maintained C++ Apache Kafka library for integration with Flutter Android/iOS app.

Software Engineer, Undisclosed Company

  • Contributed to creating, maintaining, and new feature developement of modern C++ real-time video processing and streaming software suite.
  • Contributed to creating new real-time video transcoders (H264, H265) using FFmpeg’s C API and C++.
  • Optimized C++ software suite to use 50% less memory and reduce CPU usage while increasing performance.
  • Created internal MPEG-TS video debugging parsing tools in C++ and Qt to aid with work and help the test team.
  • Aided in horizontally scaling software suite to a multi-node environment using Apache Kafka and C++.
  • Automated software suite installer generation using Python.
  • Aided in automated software suite’s build and packaging process using, Jenkins, and Atlassian products.
  • Aided in designing, creating, and testing of internal libraries to unify software suite’s codebase.
  • Researched using Rust for core library development and integration with current C++ Qt software.

CS Research Assistant, Undisclosed Company

  • Created C# programs and Python scripts to aid in mining data from research papers for AI processing.
  • Researched and created Python software based on EBSD research papers to verify paid-software’s results.
  • Created Python software to interact with paid-software’s DLLs and hardware to automate said software and hardware’s processes.

CS and Physics Tutor, Undisclosed University

  • Tutored mutiple students in CS and Physics weekly on-campus
  • Solidified course concepts and aided in teaching students based on their needs in 1-hour sessions.

Skill Summary

  • Proficient in C++, Qt, Python, Vue.js/Nuxt.js, Javascript, Java, and Flutter programming languages.
  • Experienced in cross-platform C++ library design and integration for all hardware and CPU architectures (including mobile).
  • Experienced in cross-platform mobile-application development in Flutter, C++, and Java.
  • Experienced in front-end and back-end development using Vue.js/Nuxt.js, React, Javascript, Python, and C++.
  • Experienced in creating cross-platform emulators of game systems using C++ and creating accompanying mobile apps.
  • Experienced in running and maintaining nodes for projects on the Ethereum network.
  • Experienced in delegating, staking, and liquidity providing on Ethereum, Polygon, and Cosmos networks.

@solidsnake Thanks for the update on that. The testing plan makes sense, especially since we know we need a testnet anyways in order to fully confirm the safety of the parity upgrade. Looks like we’re going to need to either the software upgrade code to force the commission changes manually just for this upgrade without doing verification checks. Not ideal, but considering our situation I’m not aware of another way around this. We can look further into this first though before committing to doing the approach I’ve described as a solution. Might be a better way.


Are there any plans to move the tax to inside the gas fees as this will allow for true parity to be achieved as well as remove the burdened of implementing a poorly coded solution to the smart contract builders, and frontend developers


Hiya @Bilbo!

The investigation into Terra Operator has been going pretty swell so far haha! I remember last time I looked at it I had concerns because it looked like the Dockerfiles were pretty bloated with a bunch of arguments and secrets being exposed in the Dockerfile as Docker ARGs, which is an insecure paradigm to have, but so far it’s looking like Vinh has done a bunch of changes for testnet refactoring to have it run via Go, which is pretty neat! I’m still reading through it all as there’s pretty substantial changes but honestly it’s looking like Vinh has done some pretty nice work here from a programming perspective! We’re still gonna definitely need to have a conversation with Vinh to get some context on Terra Operator and their exact intended usage for it so we can be sure we’re on the same page with it! One thing I think we need to do for sure after having had some time to look at it is that we need to really bolster out our test cases! Especially if we’re going to do chaos testing on CI!

Hey @Andrew_Kerslake!

I can talk to this one for the team! We’d like to look deeper into this for sure, since I know Bilbo has told us quite a few people have approached him about it! So it’s something we’d be happy to look at after parity! Thanks for the question!


With the minimum commission would it be possible instead of forcing validators on to the 5% to take 5% from their delegators or what ever percentage is required to make up the 5% minimum and send that to the community pool, this should then convince the validators running their nodes to either up the commission or risk losing funds


Hey @Bilbo,

I’ve looked at the Oracle Feeder changes more, as well as the issues A.E brought up that you sent me screenshots of. I’m going to spin up my own node for testing purposes on the Oracle Feeder to see what the usage is like from a clean install, and walk back from there. If it does indeed end up being an issue then that’d mean that this task wasn’t actually completed in Q1 despite LuncBurnArmy saying it was, and we wouldn’t be able to deploy this to validators. Technically validators can run whatever feeder they want, and they don’t really need a governance vote to run a specific version of an Oracle Feeder / Price server on their machine, but that’s a different matter unrelated to this.

@Andrew_Kerslake - I can take this for Snake. It doesn’t really seem fair to delegators to punish them for the actions of their validators by impacting their staking rewards, and the complexity to do this kind of change would be more then the complexity that would be involved in just forcefully upgrading the validator’s minimum commissions by bypassing the commission change checks for the software upgrade. Thanks for the question!


Just wanted to hop in to say I am loving this! Great idea :bulb: Good luck!


Dev Team,

Have you looked at Redlines USTC proposal?
Do you think it is feasible?
Does it align with some of the concepts your team has for thought about?

Do you have any contacts and connections with Dapps from Luna 2.0 that have expressed interesting in joining this chain after parity is reached?


Where is the ama sir


Hey team, first of all thank you taking the time out of your day to answer questions the community has to ask you. That being said my question is since the recent departure of senior developer Zaradar leaving the L1JTF and the development being fractured as of writing this, will you provide an overview of the state of coding that was given for the compensation that was paid out of the community pool? Many of us are blue collar workers and we do not simply possess the linguistics for that language. We’ve heard so many narratives being pushed time and time again (trust terra rebels, trust l1jtf) and the development team has more or less been a revolving door of experimental teams.


Haha thank you for the positive feedback! :slight_smile:

I’ve looked at the first iteration from a couple months back, but not the new one in detail yet! I’m planning to give it a read later this evening after the AMA! @mangochutney @Bilbo @solidsnake how about you guys?

I also don’t have any connections with dapps from LUNA 2.0, but a chain that has parity and an easy migration path should be welcoming to any dapps in my opinion!

You’re in it! :slight_smile: Welcome!


The Q1 dev team was solely focused on upgrades and coding requests by Binance.

  1. Will you guys focus more on community requested features? 5% minimum commission being an example. Lots of time has passed since it was voted in. Do you expected implementation will speed up once you take over?

  2. Other poor aspect of previous team was communication with people who want to build on LUNC. How do you plan to handle that? Will you have a point of contact person of some kind?

  3. LUNC has a new Whitelist feature developed at the request of Binance. However, they still burn 50% of their fees instead of 100%. Do you plan on communicating with them and working towards returning to 100%

  4. Would you be able to onboard other exchanges (whitelist for burns) if such an inititive is voted in by the governace?


@chopstick.sensei I’ve read Redline’s prop in brief, but I’m giving it a deeper read tonight as well. The focus is parity first though. We can’t do some of the things we want to do to help the repeg and attract new liquidity on-chain like the Alliance Modules with other chains and USTC Staking without achieving parity first.

@STALKER Thanks for the question. I think we need to get to a place as a chain where any senior developer leaving the chain isn’t as dramatic or destabilizing of an event as Zaradar leaving the L1 JTF was. We need to stop putting all our eggs in one basket as a community, because it always ends up centralizing power, creating vectors of abuse and manipulation where previously none existed, and pushes out other individuals from wanting to contribute to the chain because of those very dynamics. Our goal here isn’t to just become “the new old boys club”, our goal is to open the chain back up to contributions from multiple individuals instead of creating an un-needed monolithic structure that everything on the chain has to run through, as it just ends up hindering growth and hampering innovation (as we’ve already seen over the course of this past year).

To specifically answer your question, we’d be happy to do an overview of the state of the code that is currently present on the chain if that’s something the community would be interested in us doing, and we’ve already looked at the code multiple times before and have noticed things that have made us ask questions that we’ve talked about in various Discords with the community, and upon getting context and knowledge transfer from the L1 JTF if the 11463 prop were to pass we’d be happy to provide that breakdown for the community if it was something they indeed did find to be helpful.

There also remains the unanswered questions as to the WASM upgrade impact analysis and assessment that LuncBurnArmy said they would do in Q1 that has yet to be shared with the community, so we’d very much like to see that as well.

@solidsnake do you mind taking @Mpowski’s question? I don’t want to hog all the questions and not give the team a chance to answer any :joy:


It’s been going well; I’ve been able to setup an run a local Terra Classic node and call basic smart contract functions updating the local node’s chain. Studying the Cosmos SDK and built-in WASM support documentation has also been enlightening, I need to spend more time trying out the WASM to get more experienced with it rather than mostly reading about it though.


@Bilbo sure no problem.

Hello @Mpowski, to answer your questions in detail:

  1. Yes. Our goal is to collaborate with and listen to the community. We know that we aren’t above the community, we’re a part of it. In regards to 5% minimum commission implementation, it certainly would be a loose thread that’s been hanging around for quite some time that we’d seek to finish up, but it’d likely come after we’ve gotten the testnet set up and have done software upgrade testing on the testnet first.

  2. To be candid, it seems like TGF has been ineffective in this front. The entity has existed for months yet no grants have been issued, and as the current state of the chain has shown centralizing this under a single entity has only served to create power dynamics where there shouldn’t be any.

Our goal is not to be gatekeepers for the chain. There shouldn’t be gatekeepers for the chain at all. That’s not how blockchains or crypto is supposed to work, and I believe we will not get anywhere significant as a chain if we try to make developers jump through these kinds of hoops with a private entity. Developers should be able to come and state their case to the community just like we are, and have a respectful open and honest discussion about the merit of what they’re trying to bring to the chain, and the community can decide accordingly based on the merits of their proposal.

To directly answer your question, if someone were to reach out to us for help on getting their dapp onto the chain, our first step would be to tell them to talk with the community, and we’d let the community know that this developer exists as well, so that the community can be the ones making the decision on what comes into their chain, not us.

  1. We would love to do this. We would also like for communication with CEXes to become more transparent with the community instead of being siloed away behind a single person, because it’s a frail paradigm from a business perspective to have all key communications with business partners in the hands of a single person (bus factor). In the crypto space this is even more important, in our opinion.

  2. Onboarding other exchanges is a community effort. From a development perspective it is very straight forward for us to add new addresses to the whitelist, and we’ll be happy to communicate with other exchanges like Kucoin or Bybit about the possibility of doing burns if that’s what the community wishes, but at the end of the day it’ll take the entire unified will and efforts of the community to help make those things happen.

@notjoshc that’s great to hear! I think you’ll particularly enjoy digging into the WASM side of things, that seems like it’ll be right up your alley. It’s definitely a fun chain to poke around in though. Cosmos is a wonderfully designed piece of software. They did a lot of things right in my opinion.


Thanks for the answers and here is some more questions.

  1. Funding and paying devs has recently been a hot topic both with the high salary to Zaradar and paying rate equal to devs to the Project Manager LUNC BURN ARMY. Question is - how will you operate without a project manager? How really important is such a role in developing an L1 chain. Can you do without it?

  2. It was recently discovered that TGF did not pay devs directly, by using LUNC. Instead funds were sent to Kraken in random-sized batches. Afterwards a large amount of transactions was made on the exchange. As a result, there is zero transparency and how much each dev was paid rrmains unknown. It also is unknown whether they received FIAT, Lunc or other Crypto.

Can you explain how payments to devs will be made in your case? Will this be simply LUNC sent to Terra Wallet of each dev so that Community can clearly see where the funds went?

  1. Social Media Conduct question. Many Community members complained about the amount of time Zaradar spent on Twitter and the type of content he promoted (FUD against LUNC, promoting LUNA, promoting Centralisation). What can we expect from your team? Will there be any internal code of conduct or NDA agreed between devs to protect the price action and investors?

  2. Updates/Investor Communications
    How will you keep us up to date? How do you plan to reach a wider crypto audience and spread positive vibe arpund LUNC?