search

hirosystems / ordhook

Build indexers, standards and protocols on top of Ordinals and Inscriptions (BRC20, etc).
Apache License 2.0
189 stars 56 forks source link

feat!: keep original deployed ticker for brc20 tokens #349

Closed rafaelcr closed 3 months ago

rafaelcr commented 3 months ago

Conserves original case of deployed ticker for BRC-20 tokens and uses it for predicate payloads.

Fixes #348

codecov[bot] commented 3 months ago

Codecov Report

Attention: Patch coverage is 0% with 19 lines in your changes missing coverage. Please review. Files Patch % Lines
...s/ordhook-core/src/core/meta_protocols/brc20/db.rs 0.00% 16 Missing :warning:
...rdhook-core/src/core/meta_protocols/brc20/cache.rs 0.00% 1 Missing :warning:
...dhook-core/src/core/meta_protocols/brc20/parser.rs 0.00% 1 Missing :warning:
...ook-core/src/core/meta_protocols/brc20/verifier.rs 0.00% 1 Missing :warning:

:loudspeaker: Thoughts on this report? Let us know!

tippenein commented 3 months ago

Not sure I understand the motivation here? Why do we need to keep a separate display value? It doesn't seem like a db change

rafaelcr commented 3 months ago

@tippenein basically, in the BRC-20 indexing rules there's a rule that says that token processing should be done case insensitive. This means that if a token is deployed with the name PEPE, further operations that are done for pepe should apply to the same token.

However, the original case of the ticker name (PEPE in this case) should be respected when displaying the token in the API, which is why we'll now save both the original display name and the lowercase name which we currently use as the primary key and foreign key in all of our BRC-20 tables.

We could store only the original case and always lowercase before processing token operations, but that would make the code a bit harder to maintain and more prone to errors.