![Custom JSON.jpg](https://cdn.steemitimages.com/DQmQWeX9oHm3Bgjfq843yB996GpYjwrCWR2L4BMDAoczcZi/Custom%20JSON.jpg)

Hello Steemians, we would like to open up public discussion of another minor addition to HF21: removing the limit to the number of custom JSON operations that can be included in a block by a single account. 

<h1>For App Developers</h1>

Many Steem developers have informed us that this limit is adversely impacting the user experience in their applications. We want to do everything we can to make sure that Steem is the best blockchain protocol for powering web applications with amazing user experiences, which is why we believe it is worth discussing this change. 

We have attempted to keep private discussions of this change to a minimum and a final decision has not been made. We would like all discussions on this topic to occur in the comments section of this post, or in follow up posts where appropriate.  This way Steem users can gain as much insight into the change, and the reasons for supporting or opposing it, as possible. 

<h1>Why Limit Custom JSON ops?</h1>

When this limit was created Steem only had bandwidth to rate-limit transactions. The big cost of custom JSON is an undo state for the plugins that process custom JSON. Because the Resource Credit is more sophisticated than the original bandwidth system, it more accurately captures that cost, and is therefore much more effective at rate limiting excessive use of custom JSON ops. This makes the limit antiquated. 

<h1>DOS?</h1>

The DOS attack that led to the introduction of this limit did not impact the reliability of the Steem Blockchain. All witnesses continued to produce blocks without interruption, but it did result in an outage on Steemit.com. There is still the opportunity for the operation to be sent in a burst which could result in a short hiccup for nodes processing custom JSON. 

<h1>Increase to 5</h1>
After weighing the pros and cons of such a change, we would recommend increasing the limit to 5 custom JSON ops per block. This will greatly increase flexibility for DAPP developers while continuing to ensure the stability of said DAPPs. This would enable us to re-evaluate the change prior to the SMT hardfork and decide to either relax the limit further, remove it entirely, or keep it where it is based on usage by DAPP developers. 

<h1>Feedback</h1>

We have done our best to ensure that private discussions of this change were kept to a minimum, and that no final decisions on this change were made. We invite those who support this change, and those who do not, to voice their opinions in the comments to this post. The goal is to give Steem users one place where they can come to learn about this change, understand the various sides, and voice their support or lack thereof.

_The Steemit Team_