# \[brc-20\] Optimization **URL:** \ **Category:** General\ **Tags:** brc-20\ **Created:** [September 19, 2023, 7:22pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33 "2023-09-19T19:22:41Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![domo](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/domo/32/10_2.png) [@domo](https://l1f.discourse.group/u/domo)\ **Post date:** [September 19, 2023, 7:22pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/1 "2023-09-19T19:22:42Z")
One of the most proposed upgrades to brc-20 is optimization. Initially conceived as a proof-of-concept experiment, little consideration was given to optimization, leading to valid criticisms. Therefore, as one of the least controversial topics, and with L1F now implemented, we believe that optimization should be prioritized in the upcoming updates to brc-20. Please use this thread to propose, discuss the pros/cons, and develop techniques to enhance the optimization of brc-20. Some initial topics to bootstrap discussion: - Metaprotocol tags: - [Add metaprotocol field by casey · Pull Request #2449 · ordinals/ord · GitHub](https://github.com/ordinals/ord/pull/2449) - CBOR (Concise Binary Object Representation): - [https://cbor.io/](https://cbor.io/) ---
**Author:** ![cbspears](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/cbspears/32/14_2.png) [@cbspears](https://l1f.discourse.group/u/cbspears)\ **Post date:** [September 22, 2023, 2:24pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/2 "2023-09-22T14:24:02Z")
I support an “upgrade” to CBOR as now the human readability benefits JSON provided have been abstracted enough across the various ecosystem UIs. It would make sense long term to move to a more compressed data standard. ---
**Author:** ![cbspears](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/cbspears/32/14_2.png) [@cbspears](https://l1f.discourse.group/u/cbspears)\ **Post date:** [September 22, 2023, 2:30pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/3 "2023-09-22T14:30:04Z")
IMO metaprotocols like BRC20 should utilize flags or fields within an inscription envelope, or even define alternative envelopes entirely. I would like to get Psifour’s opinion on the specific metaprotocol field implementation suggested by Casey. I believe that he thinks it could be handled more elegantly, so I would urge caution on embracing that field at this time. ---
**Author:** ![conduition](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/conduition/32/83_2.png) [@conduition](https://l1f.discourse.group/u/conduition)\ **Post date:** [December 19, 2023, 2:10am UTC](https://l1f.discourse.group/t/brc-20-optimization/33/4 "2023-12-19T02:10:07Z")
I would be happy to work towards standardizing a new and more efficient binary representation of BRC20 inscriptions. Judging by how many inscriptions transactions are in the mempool, i think this would go a great distance towards improving conditions in the fee market. It would also make BRC20 much cheaper to transact. ---
**Author:** ![domo](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/domo/32/10_2.png) [@domo](https://l1f.discourse.group/u/domo)\ **Post date:** [December 21, 2023, 1:17am UTC](https://l1f.discourse.group/t/brc-20-optimization/33/5 "2023-12-21T01:17:41Z")
Hello @conduition, thanks for your message. We created L1F to provide a platform for contributors like you to actively influence and shape the standard. We want to be transparent about our progress: updates like optimization haven’t been advanced yet because our primary focus has been on establishing a robust and stable foundation for indexing and validation in brc-20. As we are nearing the completion of this phase, it’s becoming more practical and safer to coordinate and execute these updates. ---
**Author:** ![conduition](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/conduition/32/83_2.png) [@conduition](https://l1f.discourse.group/u/conduition)\ **Post date:** [December 22, 2023, 5:16pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/6 "2023-12-22T17:16:12Z")
Given that a large proportion of the mempool and block space is currently being taken up by BRC20 transactions containing a lot of unnecessary JSON data, i’d say optimization should be done _before_ trying to stabilize anything. The current protocol shouldn’t become a robust standard given how inefficient it is. @domo where would be the right place to propose changes? Is there anywhere I can file a PR against the spec? ---
**Author:** ![conduition](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/conduition/32/83_2.png) [@conduition](https://l1f.discourse.group/u/conduition)\ **Post date:** [December 22, 2023, 5:18pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/7 "2023-12-22T17:18:52Z")
This is out of scope, but a slightly more efficient form of BRC20 has been concocted in the form of CBRC20: blog [dot] ordinalhub [dot] com/what-is-cbrc-20/ - however this is still not as efficient as direct binary encodings. ---
**Author:** ![honeycake143](https://avatars.discourse-cdn.com/v4/letter/h/b3f665/32.png) [@honeycake143](https://l1f.discourse.group/u/honeycake143)\ **Post date:** [December 30, 2023, 12:30pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/8 "2023-12-30T12:30:35Z")
Hi Domo，Would you please take a look at the BRC20-E proposal from BNSx？Thanks The BRC20-E Proposal. One of the key innovations of BRC20-E is the addition of the “e” field in its JSON structure, enabling extension. It also includes the “d” field for BASE64-encoded data, which can be decoded using the protocol’s protobuf design. 🔹 Efficient Data Usage: BRC20-E smartly minimizes additional data submissions to the BTC. Less data means lower costs, making your transactions more efficient and wallet-friendly. 🔹 Unified Protocol Design: With its uniform protocol structure, BRC20-E ensures seamless integration and understanding across the #BRC20 ecosystem. This unified approach translates to more streamlined operations and, in turn, cost-effective transactions. 🔹 Immutable and Reliable: Once deployed, BRC20-E’s protocol extensions are set in stone on the BTC network. This immutability guarantees stability and consistency, leading to fewer disruptions and associated costs. 🔹 Empowering the BTC: BRC20-E not only enhances the existing functionalities of the BTC but also opens up new possibilities for tokenization, all while keeping your gas fees low. The full proposal link please check their twitter account Twitter @thebnsx ---
**Author:** ![seraphim](https://avatars.discourse-cdn.com/v4/letter/s/ad7895/32.png) [@seraphim](https://l1f.discourse.group/u/seraphim)\ **Post date:** [December 30, 2023, 3:35pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/9 "2023-12-30T15:35:09Z")
Hi Domo，Would you please take a look at the BRC20-E proposal from BNSx？Thanks The BRC20-E Proposal. One of the key innovations of BRC20-E is the addition of the “e” field in its JSON structure, enabling extension. It also includes the “d” field for BASE64-encoded data, which can be decoded using the protocol’s protobuf design. 🔹 Efficient Data Usage: BRC20-E smartly minimizes additional data submissions to the BTC. Less data means lower costs, making your transactions more efficient and wallet-friendly. 🔹 Unified Protocol Design: With its uniform protocol structure, BRC20-E ensures seamless integration and understanding across the #BRC20 ecosystem. This unified approach translates to more streamlined operations and, in turn, cost-effective transactions. 🔹 Immutable and Reliable: Once deployed, BRC20-E’s protocol extensions are set in stone on the BTC network. This immutability guarantees stability and consistency, leading to fewer disruptions and associated costs. 🔹 Empowering the BTC: BRC20-E not only enhances the existing functionalities of the BTC but also opens up new possibilities for tokenization, all while keeping your gas fees low. The full proposal link please check their twitter account Twitter @thebnsx ---
**Author:** ![BNSx](https://yyz1.discourse-cdn.com/flex007/user_avatar/l1f.discourse.group/bnsx/32/93_2.png) [@BNSx](https://l1f.discourse.group/u/BNSx)\ **Post date:** [December 30, 2023, 4:45pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/10 "2023-12-30T16:45:26Z")
the BNSx community here made an extension proposal for BRC-20 protocol which named **BRC20-E** Protocol, we did some work to solve the protocol continuity issues and saving gas problem. The details could see in our github’s proposal repository, ---
**Author:** ![kj-03](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kj-03](https://l1f.discourse.group/u/kj-03)\ **Post date:** [January 2, 2024, 9:18am UTC](https://l1f.discourse.group/t/brc-20-optimization/33/11 "2024-01-02T09:18:37Z")
i was thinking a proposal that both decentralize the indexer and check the state more faster as BRC20 not supporting the global state, wallet need to construct the account by themself. ---
**Author:** ![Foreverforestt](https://avatars.discourse-cdn.com/v4/letter/f/67e7ee/32.png) [@Foreverforestt](https://l1f.discourse.group/u/Foreverforestt)\ **Post date:** [January 11, 2024, 7:33pm UTC](https://l1f.discourse.group/t/brc-20-optimization/33/12 "2024-01-11T19:33:55Z")
Hello. I came from Twitter, I love discovering new ideas. They do research, I saw Layer 1 Foundation. Good luck.