This proposal aims to launch the first Threshold Signature Scheme (TSS) group on BandChain, using the bandtss module. The group will consist of 12 validators, and any message will require at least 8 signatures to be considered valid.

As this is the first TSS group, we are selecting validators who have worked closely with the Band Protocol team during the development and testing phases. Their familiarity with the system and continued collaboration make them well-qualified to help ensure a successful launch.

Initial validator set for the first TSS group:

Validator Name	Address
Dijkstra	band1r00x80djyu6wkxpceegmvn5w9nx65prgvpz48t
Kruskal	band1f6htx23e4xfu0dkpa2ck2kk63la2ej94jwyvt7
Knuth	band1wja9nds8klxcjurvxerdsun4t52zfjvqdy7837
Tarjan	band1m88fha4982ev7smptzu8a7wvt8wkxdvf4cnf7x
Hamming	band128dkddh98pfwdxg07t36fxedczthg0p2hmunsp
Sorawit	band1ycs4g7xu8wmf7n4vwwtfsvhtfm7tekvw683qrf
Cosmostation	band17d3uhcjlh4jyqcep82jfsrg8avsngklx2thhwr
Nansen	band1c9ye54e3pzwm3e0zpdlel6pnavrj9qqvlrnumc
B-Harvest	band1q894x7p4ugl3q5l47e8ksll5k5lmx74f2kap30
Forbole	band14kn0kk33szpwus9nh8n87fjel8djx0y0z5sv0f
Stakecito	band1p26kdh5fx24qz9xa5jtjje8ha8ee9q44l45mzn
Active Nodes	band1nqmeykpnqdccxf2kfqnwszy748ll3qlzsen6pq

We sincerely appreciate the continued contributions of all validators in the BandChain community. Your support is essential to the growth and success of the network.

Context

The purpose of this proposal is to upgrade BandChain to v3.1. This upgrade will roll-out these features on BandChain.

• Bump cosmos-sdk version to v0.50.14.

Upgrade block and date:

This upgrade is expected to occur at block 42450000. (Estimate date is July 17, 2025 at 12:00 UTC)

Context

The purpose of this proposal is to upgrade BandChain to v3. This upgrade will roll-out these features on BandChain.

• Bump Go to v1.24.2, Cosmos SDK to v0.50.13, CometBFT to v0.38.17, IBC-Go to v8.7.0, go-owasm to v0.3.1
• Add new modules: tss, bandtss, feeds, tunnel, restake, rollingseed, and globalfee.
• Introduce new mempool with transaction lanes and prioritization
• Add Grogu and Cylinder programs to support feed price submission and TSS operations

Upgrade block and date

This upgrade is expected to occur at block 42051400. (Estimated date: July 8, 2025 at 12:00 UTC)

On-Chain Upgrade Process

When the network reaches the halt height, the BandChain state machine will stop. Validators and node operators must replace the binary with the v3 version. We recommend using Cosmovisor to handle the upgrade automatically. The chain will resume from the same height with full history.

Context

The purpose of this proposal is to adjust two parameters, specifically MAX_CALLDATA_SIZE and MAX_REPORT_DATA_SIZE , in order to expand the new use-cases of the Band Oracle. This expansion is particularly needed for oracle data generated by generative AI which requires larger input and output sizes.

The proposed changes are as follows:

• Increasing MAX_CALLDATA_SIZE from 256 to 4096 to allow for a larger maximum byte size of calldata.
• Increasing MAX_REPORT_DATA_SIZE from 512 to 4096 to enable a larger maximum byte size for reports from validators.

Effects

For All Validators: All validators providing oracle data will need to adjust MAX_DATA_SIZE in the data source executor to 4096.

For Users/Developers: They will be able to create DS/OS with larger input and output.

Summary

• As part of our overall decentralization roadmap, this proposal aims to establish the official Band Protocol Grants Program for the Band community.
• The purpose of this proposal is to secure funding from the community pool of Band Protocol in order to support the official Band Protocol Grants Program and advance the growth of the Band Protocol community
• As of the date of submission, we are seeking approximately 20% (or 150k BAND) of the total funds available in the community pool, which currently stands at ~800,000 BAND. This pool, derived from 2% of block rewards and network fee, has remained untouched thus far.
• The requested funds will be allocated to support contributors in the first wave of the grant program. The grant program operates on a four-wave per year basis, with a maximum funding limit of 150,000 BAND per wave. To reinforce the decentralization of the network, the proposed grant program will be governed by the existing Band token holders.
• All BandChain Grants Proposals (BCGPs) will undergo a review process led by the grants team lead and will be reviewed by three supported reviewers using the BCGPs process
• The grants program will commence once the proposal has been approved.

Purpose

To successfully achieve decentralization, Band Protocol recognizes the importance of building a robust and active community. As part of our ongoing efforts to further decentralize the network, we are introducing a grant program that will be governed by the existing Band token holders.

The primary objective of Grants program is to enhance the Band community and increase the long-term effectiveness of BandChain by rewarding individuals who contribute values that support BandChain.

The grants program aims to:

• Expand the Band ecosystem, funds will be provided for development activities aimed at adding value and ensuring the long-term success of BandChain.
• Support and fund innovative ideas that enhance the Band ecosystem.
• Provide funding for value-added projects, ideas, and community events to encourage more active participation from contributors. The growth of the Band ecosystem depends on the community, and this will benefit it while attracting new members to the Band community.

From onset, BandChain has maintained Band tokens in its community pool, which steadily increases by around 19,000 BAND per month through the allocation of 2% of block rewards and network fee. And so far this has accumulated 800,000 BAND which have not been utilized before and it is essential to actively utilize these funds to add value to the protocol and its ecosystem. As part of an effort to further decentralize the network, we are proposing a grant program governed by the current Band token holders.

The grants program will establish a maximum funding limit of 150,000 BAND per wave, and the program will operate on a quarterly basis, with four waves per year.

The BCGP was established with the aforementioned goal in mind, and contributors can apply for and obtain $1,000 to $50,000 worth of BAND under the funding conditions, which is a sum that would not be viable for governance funding via on-chain voting every single time. We recognize that having funding for operations and development is crucial for contributors, which is why we encourage them to be active and grow the ecosystem in the long run.

Scope of work

During the initial phase, Band core team will help to create all the essential procedures and resources for the program, including the Grants website, Band forum, and application process. If the program operates efficiently on its own, it will slowly shift to the community, enhancing its long-term sustainability.

The program’s scope extends beyond providing funding to individual contributors, as it also encompasses talented teams that are developing value-added projects. Our objective is to support the Band Ecosystem by allocating grants to projects that generate significant benefits for the community.

There are 4 categories to support Band Ecosystem:

1. Development Grants: Grants for developers building blockchain-based applications and services on top of a particular platform.
2. Research Grants: Grants for academic or industry researchers studying various aspects of blockchain technology, such as scalability, security, privacy, and interoperability.
3. Community Grants: Grants for projects that promote the adoption and growth of a particular blockchain ecosystem, such as meetups, hackathons, educational initiatives, and marketing campaigns.
4. Infrastructure Grants: Grants for projects that improve the underlying infrastructure of a particular blockchain ecosystem, such as improvements to consensus algorithms, network scalability, or storage efficiency.

Grants Team

The initial introduction of the grants team by the core team of Band will include individuals who have been working closely with Band for over three years. These team members possess diverse skill sets, extensive experience, and share a common goal of ensuring the long-term success of BandChain.

Here are the proposed initial members of the grants team:

1. Grants Team Lead:
   • Shine - Head of Operations, Band Protocol
2. Reviewers:
   • Swit - CTO, Band Protocol
   • Paul - CPO, Band Protocol
   • Queue - Senior Software Engineer, Band Protocol

Since the grants team is affiliated with Band Protocol and are pre-selected for an initial starting period, they will not be compensated using the requested grants fund. Therefore, the entirety of the funds in the community pool will be dedicated solely to contributors.

The grants team will remain operational until the program achieves self-sufficiency, with a planned experimentation period of one year. Furthermore, community members will be able to volunteer and garner votes from Band token holders and the community, opening up possibilities for them to join the grants team down the line.

The team will have the following responsibilities:

• Operations : As soon as the applications for the BCGP are received, the grants team will establish an efficient operational process.
• Review BCGP : The team will review all applications bi-weekly.
• Feasibility Testing : The team will interview contributors to clarify information, agree on funding terms and amounts, and discuss with the Band core team and advisors to ensure that the grants are valuable.
• BCGP Approval : The team will approve BCGPs that meet the criteria.
• Provision of Funds : The team will provide the funds as per the agreed terms of the contributor and grant team’s agreement.
• Follow-Up : The team will hold a follow-up meeting with the grantee to ensure that they achieve any milestones and generate a final report for the community.

Granting Process and Timeline

After the approval of this proposal, the grants program will initiate, comprising of four cycles annually, with each cycle spanning three months. Community members are encouraged to submit their applications through the Band forum within the designated grants program timeframe. Evaluations of the approved applications will be conducted using the BCGP processes approximately one month prior to the conclusion of each cycle. Any proposals submitted during this timeframe will be considered for the subsequent cycle.

The grants team will source and discuss potential BCGP with the Band core team and advisors to ensure that it benefits the Band ecosystem. If everyone agrees on the BCGP, the grants team will interview the contributor to clarify information, agree on milestones, funding terms, and grant amounts. The grantee will then apply for the BCGP on the grants website and prepare for the final approval.

Upon submission of the BCGP on the website, the grant team will review all the information and give the final approval. After the reviewing status of BCGP changes to the implementing status, the grant team will fund the grantee within seven days following the terms of the agreement. And the fund will be paid in BAND for worldwide applicants, except for those located in the United States, who will be paid in USDC instead.

Context

The purpose of this proposal is to upgrade the BandChain to v2.5. This upgrade will roll-out these features on BandChain

• Bump ibc-go to v4.3.0 due to v3 has reached the end of life and requires coordinating upgrade
• Bump cosmos-sdk to v0.45.15, tendermint (cometbft) to v0.34.27, and go-owasm v0.2.3
• Support statically linked binary for bandd

Upgrade block and date

This upgrade is expected to occur at block 16562500. (Estimate date is April 27, 2023 at 14:00 UTC)

On-Chain Upgrade Process

When the network reaches the halt height, the state machine program of the BandChain will be halted. This classic method for upgrading requires all validators and node operators to manually substitute the existing state machine binary with the new binary. We recommend validators to use Cosmovisor to swap the binaries automatically. Because it is an on-chain upgrade process, the blockchain will be continued with all the accumulated history with continuous block height.

Instruction to prepare v2.5 binary: https://github.com/bandprotocol/launch/blob/master/laozi-mainnet/docs/prepare-for-upgrade-v2.5.md

Context

The purpose of this proposal is to introduce network fees on the BandChain mainnet. The team strongly suggest validators to set the minimum gas price to 0.0025 uband to achieve the below objectives:

• Prevent spam events on the BandChain
• Provide incentive for actors to be good actors within the Band community (e.g. validators and data providers to be rewarded for completed work)
• Progress towards a self-sustainable decentralized ecosystem

Gas price

The minimum gas price will be set to 0.0025 uband to achieve the objectives stated above. This number came as a result of experimentation and testing to strike a balance and set the gas price to discourage attacks and network spams, derived from associated costs required to perform such malicious attacks, without creating a hindrance to the services.

Decisions

Yes

1. Foundation nodes will set minimum gas price on each node to 0.0025 uband on the 1st of February 2023
2. All validators are strongly encouraged and recommended to update minimum gas price to 0.0025 uband on the 1st of February 2023
3. The core team will prioritize implementation of minimum gas price at protocol level, which will be detailed in subsequent upgrade proposal

No

A “No” result would signify that the Foundation nodes will not update minimum gas price and would force a reconsideration for the team on security

Effective date

The minimum-gas-price is to be set on the 1st of February 2023

Effects

Builders and developers of the BandChain ecosystem

• Validators must update minimum-gas-prices in $HOME/.band/config/app.toml to “0.0025uband” and restart your node on the effective date.
• BandChain users must update their gas_prices in transactions before the effective date.

Context

The purpose of this proposal is to upgrade the BandChain to v2.4. This upgrade will roll-out these features on Bandchain

• Bump cosmos-sdk to v0.45.10 and ibc-go to v3.3.1 to fully support state sync and ICA-host
• Increase the throughput for oracle module by ~10X from optimizing owasm runtime
• Increase the MaxGas per block to 50M Gas

Upgrade block and date

This upgrade is expected to occur at block 11525000. (Estimate date is November 21, 2022 at 14:00 UTC)

On-Chain Upgrade Process

When the network reaches the halt height, the state machine program of the BandChain will be halted. This classic method for upgrading requires all validators and node operators to manually substitute the existing state machine binary with the new binary. We recommend validators to use Cosmovisor to swap the binaries automatically. Because it is an on-chain upgrade process, the blockchain will be continued with all the accumulated history with continuous block height.

Instruction to migrate to use cosmovisor: https://github.com/bandprotocol/launch/blob/master/laozi-mainnet/docs/migrate-bandd-binary-to-cosmovisor.md

Instruction to prepare v2.4 binary: https://github.com/bandprotocol/launch/blob/master/laozi-mainnet/docs/prepare-for-upgrade-v2.4.md

Effects

• Users/Developers: After the upgrade, you will need and are advised to redeploy your oracle scripts to reduce used gas for oracle requests

For full details of upgrade please see this article: https://medium.com/bandprotocol/bandchain-v2-4-upgrade-70dbb896618c

Context

The parameter max_raw_request_count sets the upper limit of how many external calls to datasource can a request make, limiting the number of sources that one request can include.

The Bandchain data ecosystems now have more data sources which can all be used to aggregate data results to secure a stronger integrity of the data request. But with the limit of max_raw_request_count a request can only currently call out to 12 sources.

The Band Protocol team proposes to increase the limit from 12 to 16 external calls per request. We think 16 is the number of sources that can strengthen the current requests without spamming data source execution on the validator's side.

Effects

Users/Developers: Able to create script and request more data sources to aggregate result.

Context

With the recent growth of usage from our partners (i.e. Mirror, Injective), there is an increase in requests that fills upto 80-90% of block’ capacity during peak periods. The proposed parameter per_validator_request_gas specifies the amount of gas required to process a request on BandChain per each validator that needs to report data. The parameter was originally initiated to the previous value to prevent spamming of requests to all validators. Now, with datasource fee activated on datasource ends, the parameter renders less necessary in preventing spamming and the protocol can take advantage of this to increase block capacity.

This proposal reduces per_validator_request_gas from 30000 to 0, decreasing the overall gas used per each request.

With each request using less gas, a block which has a gas limit of 8 million can take in more requests, allowing BandChain to process more requests in one block and increase capacity to serve growing data demand of partners. Specifically, this will increase BandChain capacity to process requests by approximately 25%.

Effects

Users: Faster requests and transactions on-chain.With less request size (by gas used), a block has more free capacity to process more requests and other types of transactions.