This is an edited transcript of the Telegram AMA the Chorus One team held with the Band Protocol team on April 16. Join our channel to take part in future discussions like this!

The AMA covered Band's oracle solution, the transition from Ethereum to Cosmos and its reasons, the go-to-market strategy, and more. To learn more about Band, check out our podcast episode with CEO Soravis Srinawakoon.

Welcome to our 45-minute AMA with the Band Protocol team. Band is building a token-incentivized oracle network in the Cosmos ecosystem. Get your questions ready!

We have Sorawit CTO and Paul CPO from the Band team joining us. Welcome @sorawit and @smiled0g, it would be great if you could introduce yourself and what you are focused on at Band!

Hi everyone! I’m Swit from Band Protocol. Excited to be here for the AMA!

Hi guys. It's great to be here and have a chat with all of you!

For those that joined that are not part of our community, Chorus One is operating staking services and infrastructure to help token holders earn rewards. We have Brendan (Strategy&BD) and me (Research&Product) from our team on, in case you have questions to us. We recently launched our staking platform Anthem that aims to help stakers to participate in staking and to see the rewards they make over time. Check it out at to try it out with any Cosmos address.

I head the tech team and Band, so focus mostly on protocol and design and make sure the engineers can deliver.

A bit about my background. Got a CS degree from MIT then went on to work at a HFT firm on Wall St. While there, I also worked on crypto trading bots, and started to get interested in crypto since then. As I learned about writing apps, I realized oracle is a real problem for developers. That’s why I’m very excited to be in this area and very passionate about solving the oracle problem.

Again happy to be here for the AMA!

My name is Paul and I'm a CPO and co-founder of Band Protocol. A bit of background about me: I got into Bitcoin in 2013 right before the Mt. Gox crash. From then I kept building and trying to use crypto throughout my early career. Most notably, I made a crypto game that has more than 800k downloads worldwide and 50k+ DAU at one point. Then I found Band Protocol with the other two cofounders.

My role at Band Protocol includes overseeing product roadmap and strategy, a bit of content writing, partnerships and tech integration as well.

That's impressive! What platform was that game using? Ethereum? Is it still around?

Oh it was on Android and Bitcoin. Basically the idea was to use Bitcoin as an incentive for users to use the app / play my games / etc. I no longer maintain the app since I work fulltime on Band Protocol now.

Ok great, let's get started on the oracle problem statement right away. Band has been around for a while: how did your perception of the oracle problem change since founding Band?

Great question. Our stance on oracle is the same since the day we started Band: We think it’s very important building block for decentralized applications.

I guess the main difference between now and then is that people started to realize this fact too. Last year, it’s actually quite challenging to make DeFi projects realize they need decentralized oracle, as they were probably focusing too much on getting the # of users. But you know from the recent oracle exploits that several protocols suffered, it’s clear that oracle is something you can’t just hide under the rug and pretend your protocol is decentralized.

What are the things you are optimizing for with your oracle design? What is proving to be the most challenging part in your opinion? This can be both from a product as well as a technical perspective.

We care a lot about developer experience in our oracle design. That’s why we opt to build on Cosmos and try to aim for a lower block time than running on Ethereum, with significantly higher throughput. In addition, I think one the most challenging parts for oracle design is how to make it suitable for different types of dapps. That’s why are very keen towards trying to make the protocol as flexible as possible.

So to solve that, we are rolling out our own domain-specific language based on WebAssmbly for writing oracle scripts (we call it Owasm!). This allows developers to craft their own oracle mechanic to server their needs (where to fetch data, how many data providers you need, how to filter outliers, how to aggregate to final result, etc).

This sounds great, what kind of capabilities would this allow? And would it also tackle the gas problem a lot of oracles currently have?

For Owasm, it allows devs to write oracle to suite their needs without needing to wait for us to write one. So it’s like smart contracts but specific for oracle operations.

For Gas problem, I assume you mean Ethereum network congestion? We mitigate that problem in two ways.

First, all data aggregation is done in our BandChain network and only one transaction needs to be submitted to Ethereum. Thus, there’s less chance of tx getting congested. In some other oracles, you will need to wait for a lot of txs from multiple data providers to be confirm on Ethereum to get the final data.

The other way we fix it is that we allow oracle data to be attached with user payload. This is quite subtle, but essentially data from BandChain can be packed and sent to Ethereum together with user transction (such as a transaction openning a MakerDAO CDP). This eliminates the need of data providers to submit data to Ethereum altogether. I think my explanation here is quite confusing TBH. Happy to discuss more.

Alright, for example, if I need data to be transmitted if a certain condition is met and only if it's met at the data level, would Owasm allow to do things like these, a kind of "pre-processing" before pushing the data to Ethereum? So basically you make the user pay for the gas cost?


Yes. user pays for a bit higher gas cost. But the real benefit is that user can’t use wrong data. Using price as an example, if you transaction to open a CDP also has ETH price attached with it, then it’s not possible for your CDP tx to use staled ETH price. It’s either confirmed together or not.

Maybe for Paul - what innovative ways are you thinking about to get adoption to Band? Seems like you are an expert in the area ;)

I think that one is simple:

Make a great product.

Oracle is the special area in blockchain where we predict that it'll become something that most project would need. Now, when we're in the product area with prominent problems but current solutions aren't good enough, the only thing we have to do is keep shipping high-quality solutions to our partners, keep iterating, and let the product speaks for itself.

So you started out on Ethereum, correct? What products are there currently? Will sth move from Ethereum to Cosmos or are you building a totally new protocol?

Correct. We currently have an active oracle network on Ethereum, with 5 independent data providers currently serving BTC and ETH prices to dapps on Ethereum. However, as we are launching BandChain, we are migrating the oracle infrastructure to our Cosmos-SDK. It’s actually a complete reimplementation of the protocol. Now as a Cosmos-SDK module.

You eluded to it a bit w the throughput - was that the main reason to move to the Cosmos SDK? How does building on Cosmos compare to Ethereum?,

That’s one of the reasons. We also want to be blockchain-agnostic and embrace the Cosmos principle. We believe the ecosystem of dapps will grow on other blockchain networks beyond Ethereum and are very keep to support as many as possible.

Interesting, are there any downsides of this approach? Would you switch to an IBC implementation once it becomes available/widely adopted for that?

Yes. We will switch to IBC once that’s ready. Downside of our current apporach is that our bridge is implementation support only one-way communication.

Can you talk about the most promising market sectors. Obviously defi is growing. But where else do you see growth coming from?

Most of the time shipping a successful product is about the timing. Right now, the sector that we see most adopted on blockchain is DeFi. We think it's a low hanging fruit that if we can position ourselves as a trusted solution, we can continue to support this sector in the long run and maintain that position.

Now when it comes to other use cases, Open internet API is super interesting! We foresee the next wave of smart contracts and dApps will be interfacing with the existing APIs and services. We're working with multiple parties in both large and small organizations to facilitate that vision.

A question around the token model. Band token is currently an ERC20, right? How will you do the migration? Once on your own chain the token will be usable for staking to delegate to validators. Is there any other purpose for the token? And for the staking, does it work exactly as on Cosmos wrt to inflation, slashing etc.? Or are there additional slashable events for providing incorrect oracle data e.g.?

We will do migration to BandChain. The exact mechanism will be annouced once the mainnet is close. The token is primarily used for staking / delegate to validators and paying for network fees and data query fee (if the data source is under paywall).

Inflation & slashing for Cosmos-related operation is pretty much the same as Gaia. In the current design, providing incorrect oracle data is not a slashable event (since it’s hard to determine what is bad). Failing to provide data for a long time can put you to jail status.

In future iteration, we may introduce some kinds of voting mechanism to punish data providers that intetionally serve bad data, but that’s still under active research.

As a data querier though, you can choose your own aggregation method, so if you really care about safely, for instance, you can say you only accept oracle data points if it’s not diverged too much from the majority, etc. So you are safe as long as most data providers are honest.

OK we have about 10min left, I'd like to ask a bit about the recently launched BandChain testnet:

What is the state of it and what are the next steps? How is the experience to launch with a decentralized set of validators? What are some of the challenges?

The testnet has gone well. We did a decentralized launch with 17 validators, all of them up at the same time and we did the first block exactly at the expected time, so that went well.

There were a few technical challenges / confusion. Examples include the fact that we use different signature scheme for validators (`seck256p1` for us vs ed25519 for Gaia) for maximum compatibility with Ethereum. (there’s a precompiled EVM for verifying seck256p1 signatures but not `ed25519`)

That caused a bit of a confusion to some validators, but nothing major!

Overall the testnet launched went very well. We will be performing some more stress tests in the coming weeks, but other than that, we should be all set for phase 0 mainnet launch very soon!

Awesome! I don't want to keep you guys for too long here - so maybe a final question to wrap up:

I saw there is a hackathon upcoming together with Agoric and Cosmos. Is the idea that people experiment with Owasm there. Do you have any ideas for ppl that are interested in building sth?

For reference:


Yep. We are doing hackathon with Cosmos and Agoric. It’s an IBC hackathon so we focus on the IBC mechanic. We actually implement our module to support IBC packets. One chain can send oracle request as an IBC packet to our BandChain and BandChain will reply with an IBC packet for oracle result.

I think DeFi is the most promising area at this stage, so very excited to see how people can utilize Cosmos cross-chain asset transfer and Band oracle to build sophisticated DeFi products!

Thanks, if there are no more questions from anyone in the channel I would wrap up here. Thank you Paul and Sorawit for joining us & thanks to everyone else asking questions and reading along!

We will support staking on Band as soon as the mainnet goes live, feel free to visit to learn more about us.

Thank you so much guys!

Thank you for having us too! Excited to be working with Chorus. If anyone has questions about us after this, feel free to come ask in