[last call] Increase the size of the memo field to 100kb and 10x the cost of bytes

Cosmos transactions have a “memo” → “note” field that allows users to put notes on their transactions. For as long as I can remember, Jae and other current and former aib team members have been interested in making a pan-cosmos social network called dither.

Thing is, that both for social and for other applications requiring permanent state storage, the current 255 bytes of memo is not enough.

Fact is that there are countless possible use cases for this kind of long running storage, including the things that become possible, and were not before.

  • agreements posted immutably to the chain by ecosystem participants for later reference
  • full-fat blogging like https://blurt.blog
  • microblogging like twitter

current state:
gaiad q auth params

max_memo_characters: "512"
sig_verify_cost_ed25519: "590"
sig_verify_cost_secp256k1: "1000"
tx_sig_limit: "7"
tx_size_cost_per_byte: "10"

new state:

max_memo_characters: "100000"
sig_verify_cost_ed25519: "590"
sig_verify_cost_secp256k1: "1000"
tx_sig_limit: "7"
tx_size_cost_per_byte: "100"

So let’s keep this proposal short:

VOTE YES to increase the size of the note/memo field to 100kb in the next routine upgrade
VOTE NO to do nothing
ABSTAIN to count towards quorum while biasing the outcome a little bit towards whomever is already winning
VOTE VETO to contribute to a veto threshold. If the veto exceeds 1/3, depositors atoms will be burned


Thank you for putting this formally to the forum.
I believe this is a step in the right direction for Cosmos as the whole infrastructure is there (OS indexers etc…), and the success of inscriptions on Ethereum as well as ordinals on Bitcoin.

As well as the use cases stated by @jacobgadikian , there are a huge amount of use cases that could be interesting including: DeFi, compressed storage image on-chain rather than linking an IPFS, name service as well as storing web-pages directly on-chain etc…

Although simple, the power this holds is actually amazing, without having to open the Hub for complete change by integrating Cosmwasm or other similar tools. Keeping it simple as well as bringing traction to the Hub (the main debate happening).

So for me it is a YES.



curious to know, there is no drawbacks/tradeoffs/risks at all doing so?
@jtremback @hxrts @jack?


big YES for me.

Thank you Jacob for putting this post up!

The Hub is already a vibrant socio-political economy, but much of the conversations happen offchain. A fully onchain institution should have an onchain social network and the memo field always felt like an underutilized feature.

Such a small change like this could have a meaningful impact on the Hub imo.


Thanks for bringing this up! I would love to work on indexing the cosmos blockchain.

This not only brings contracts to cosmos, it also enables builders to come up with more innovative solutions.
This is definitely a yes from me!

A big YES from a small validator (unless, of course, someone can show that it has some technical flows as a result)

1 Like

This would need some serious gas costs in order to prevent spam. 10k transactions with the full 100kb memo would add another gigabyte to the already pretty heavy storage.

I think I’d like to see some more clear use-cases to justify why we’d want to expose the Hub to this. I also don’t really understand how social networks or blogging fits within the Hub’s purpose. Cosmos Hub isn’t Twitter.

If there are clear use cases like allowing validators to make statements on governance proposals, then I’d suggest limiting extended memos for these specific users and a limited set of transaction types.


IMO you should pay for the transaction size in that case, 100kb transaction will cost differently than a 1kb transaction. I think this would offset the cost of storage for validators as well as bring more use-cases to the Hub.

I do agree that we need to specify clear use-cases, but in general I believe that it would open the door for testing some cool stuff, whether in DeFi, blogging, promissory commitments for IBC etc…

If 100kb is too big of an ask, there is a compromise somewhere that could be done where we could open a testing ground for what use cases could come out of it.

ETH and Bitcoin support much larger call_data, so it might be worth a shot with the Cosmos Hub.


Hi Noam,

In fact, I agree with you.

There’s no need to make 100kb memos cheap at all. Better make them rightly expensive so that if they become popular, the cost of storing them is offset.

2tb = $200 * 2 (cause gotta raid and use Samsung 990s but they’re overpriced where you are – best buy has them for $135/ea in USA)
200/tb (if raid and overpriced) 1gb = .2/yr (let’s say drives last a year)
validator labor $600/mo per chain - 7200 per year

base cost

7200 * 180 validators = 1,296,000

1200 per year based on common equipment rental prices and common equipment purchase prices

per tx cost

(Note I need a lil research help on current cost to put 100kb on Gaia, the banana king can help here, I’d gladly fund the research)


648,000 100kb txns needed at $2 each to cover total validator base cost


129600 100kb txns needed at $10 each to cover total validator base cost


This is not yet complete. I think that we could make these a rather expensive luxury good. I also think that there might be other applications for these larger transactions, and there is a good deal more math that needs to be done, this is just a sketch.


Bytes are waaaaay too cheap. - @valardragon

The price of the brick must go up.

@effortcapital – I think that it makes sense to move forward on this item, and pretty quickly. 10x the price of bytes (read and write is about 80% of the cost of transactions, per @zaki_iqlusion – so, bytes are underpriced for sure)… so, without causing problems for anyone because of the use of x/globalfee for ibc infrastructure, we can:

  • increase the size of the memo field to 100kb to enable ideas like Dither
  • increase the price of gas for bytes by 10x

I – think that this is a safe, sensible approach to allowing for the hub to be a permanent storage mechanism, and pricing that appropriately.

1 Like