2021 BCH upgrade items brainstorm

We introduced a new customisable dividend tool that is automated in the Zapit wallet as demonstrated here. We had to hardcode a limit of 900 addresses due to the 50 transaction limit (as each SLP transaction can have only 18 outputs).

Most of the token projects with some sort of utility will have to send dividends/airdrops to well over 900 addresses which isn’t possible due to the current 50 transaction limit. Of course one can always send out manually but its a huge blow to user experience which we at Zapit are focusing on.

The dividend tool can be used by any regular individual without much knowledge about BCH since everything is automated but the 900 address limit is still a problem if larger projects want to use the tool.

We also reward users using a payment interface that has millions of transactions per day. To tap into that market, we need to make sure that the limit is at least raised before we move forward with onboarding more users.

As we want to be able to send rewards every time users make a transaction with that payment interface, if there are more than 50 users that have to be rewarded within 10 minutes, we face a problem.

1 Like

while the 50 limit will likely be worked on in the near future, isn’t the limit for 18^50 instead of 18*50? It’s just slightly more complex arithmetic :smiley:


Multiple OP_RETURNs

Description in a couple sentences what the change is technically

Change in either standardness rules regarding OP_RETURN to allow multiple outputs with OP_RETURN in the same transaction, or change in interpretation of OP_RETURN itself to use it as a separator within the same OP_RETURN output.

Problem it’s trying to solve

Making OP_RETURN based protocols interoperable.

Potential positive impact on ecosystem

By supporting multiple OP_RETURNs in a way that makes it possible to have interoperable OP_RETURN protocols, we signal to developers that are interested in making such protocol that BCH desires their business. This would allow new usecases as well as empower existing usecases, ultimately working towards more adoption and a stronger network effect for BCH.

Potential negative impact on ecosystem

Depending on developer preference, could be a point of contention.
Depending on implementation, could end up encouraging more data storage on-chain.
Depending on implementation, could disrupt existing OP_RETURN based protocols or tooling.


This feature has become rather urgent for our development. Is there an ongoing topic in place here about it or should I create a new one? We’d really like to see this get included in May’s fork and I’d like to address any concerns or blocker asap.

This feature means multiple op returns?

I know someone will soon publish a more comprehensive suggestion about how to go about proposing and moving network upgrades ahead. In the meantime, I think the TLDR is that if anyone has a specific requirement and believes it is a good idea for the network as well, then they would need to create and own a proposal to do it. The proposal can have any level of detail on problem statement, implementation, RFC, etc. as long as it starts somewhere and the owner is committed to an iterative exploratory process with no expectation of eventual inclusion. In other words, a shared process is our arbiter and there is no single entity that can make it happen.


I’m preparing that now with details of our protocol that has the requirement of multiple OP_RETURNs so it would serve as a real-world use case. If that person wants to forward their suggestion on organizing proposals we might be inclined to be their guinea pig.

– Ben Scherrey

1 Like