I guess what I’m driving at is this: what is the taxonomy of the current near the limit transactions? 76 bytes is say a 4 byte prefix, 32 byte hash and 40 bytes worth of meta data. It’s possible that for the vast majority of transactions using op return these near limit totals are the sweet spot that accomplish something worthwhile and generally need 60-90 bytes to achieve. The filter perhaps drives some near term efficiency but over time the economics determine what happens. Perhaps the time stamping and 2nd layer anchoring that makes up the the majority of use case for larger than 40 byte op return transactions naturally cluster around this point because it is close to the sweet spot between economic worth whileness and ease of implementation. The economics could be that limit and all the filter does is create a cliff like drop off vs a gradual slop downward that would occur under purely economic pressures. The over all dampening effect of filters may be vastly over stated by your data if it turns out there is not much natural demand for Say 95 byte plus transactions. If there is ever economic value in 100 byte transactions I expect no amount of filtering will matter. I just don’t think there is a ton of demand above what is being made use of currently. I don’t know about you but when I look back at my transactions for my early use I cringe at the number of sats I parted with to fees. I think this psychology mechanism will only get amplified as the average user isn’t sitting on large stacks of corn.