Proposal: Allow Named Assets to Start with “A” (simple legacy fix — Davesta & Adam were supportive)

[arwyn6969]

Hi everyone,
Quick proposal for a small but high-impact change: let named (alphabetic) Counterparty assets start with the letter “A”.
Current situation (still the same in 2026):
• Named assets (4–12 uppercase letters) cannot start with “A”.
• Numeric assets start with “A” + long digits (free to create).
• Subassets already allow “A” (e.g. BACON.apple).
This restriction looks like it was just an early oversight or visual-namespacing choice when Adam Krellenstein added free numeric assets back in ~2014. As discussed in the Twitter Spaces/community calls with davesta and Adam, it was seen as a non-technical quirk with zero collision risk (pure letters vs. “A” + digits).
Why it would be awesome:
• Instantly unlocks great branding names like APPLE, APEX, ATOM, AURA, ALPHA,etc.
• Makes Counterparty way more attractive for new projects, memes, and real-world use.
• Easy positive news: “Counterparty unlocks A-names — better branding power on Bitcoin!”
The change should be trivial and have zero impact on anything existing.
I don’t want to take on the whole thing myself, but I’d be happy to help draft and submit the formal CIP (and any documentation updates) if Adam, maintainers, or wallet devs are supportive and want to move it forward.
What do you think? Any objections or thoughts? Especially keen to hear from davesta, Adam, and the core team.
Let’s see if this is an easy win for everyone! 🚀

[adamkrellenstein]

Easy to do and would be a strict improvement, but would definitely need broad community support.

[davestaxcp]

I am in favor personally

As Adam said we need:

• very broad community support for this

In my opinion we also need:

• a block start date (with ample time to prepare)
• infrastructure providers updating in time to support front end users to issue the new 'A' tokens

[Ouziel]

+1

[droplister]

Seems ok to me, just need to check and update places in my code that check is_numeric.

[jdogresorg]

As one of the largest asset holders on XCP (40,000+ asset names), I oppose this change as it changes the rules which have been "set in stone" since the beginning. Since assets that start with A have not been allowed to be registered as named assets, the general consensus has been for users to prefix their A asset name with X (XAPPLE, XAUTO, etc). Changing the rules 10+ years later to allow assets named with A puts users who spent XCP registering XA asset names with the understanding that the rules would not change, at a disadvantage)

At the very least, the protocol should credit back the 0.5 XCP used to register XA asset names to asset holders, since they would have never registered pointless XA asset names had the protocol been better planned out and allowed A asset names from the beginning.

not to mention that this change could break some code in wallets/sites which follow the simple rule that "If an asset begins with A, it is numeric".

[ouziel-slama]

As one of the largest asset holders on XCP (40,000+ asset names)..

I don't see how that gives your opinion more weight or grants you a veto right. The goal is to reach consensus — not to make decisions that only serve the interests of the "wealthiest" holders. Besides, those assets hold no value if nobody uses Counterparty, and this change is precisely meant to increase adoption.

the rules which have been "set in stone" since the beginning...

Oh really? Since when are any rules "immutable"? I'd invite you to take a look at https://github.com/CounterpartyXCP/counterparty-core/blob/master/counterparty-core/counterpartycore/protocol_changes.json

the general consensus has been for users to prefix their A asset name with X (XAPPLE, XAUTO, etc)...
At the very least, the protocol should credit back the 0.5 XCP used to register XA asset names to asset holders...

Nobody ever forced you to mint all those assets! You made a speculative choice in a protocol that has always evolved. The risk of value depreciation is inherent to any investment in an open-source system under active development. It is not the community's responsibility to absorb your personal risk-taking.

not to mention that this change could break some code in wallets/sites which follow the simple rule...

Parsers that assume if asset.startsWith('A') → numeric will indeed need to be updated. But that's precisely why @davestaxcp is proposing a block start date with ample lead time. This is not an argument against the proposal — it's an argument for handling it properly, just as we do with every other protocol change.

[jdogresorg]

I don't see how that gives your opinion more weight or grants you a veto right.

I didn't say that my opinion mattered more than anyone else, simply mentioned it to say that I spent a good amount of funds registering names with the understanding that A names were unavaialable, and was told many times by CP devs at the time that A would never be available because of a technical limitation. Changing the rules now not only means the funds I spent were entirely wasted, but also puts all users who followed the rules and registered XA asset names at a big disadvantage, as now their assets are worthless, and other users are going to be able to register asset names which XA asset owners had intended to register.

And, allowing A names is not going to bring some huge wave of adoption, just like adding atomic swaps, fair mints, and the other changes you have made have not.

Oh really? Since when are any rules "immutable"?

Yes ouziel, I am well aware the protocol changes, but there are some things which were communicated to the community many times over many years which were believed to be true. For instance, "There will only ever be a single burn, no more XCP will ever be created", and yet here we are years later with you guys creating more XCP and trying to frame it as "it isn't creating more supply, its just moving a decimal point". IMO this is just another case of you guys doing what you want.

It is not the community's responsibility to absorb your personal risk-taking.

I did not say this... once again, your trying to put words in my mouth... How about you simply focus on addressing technical issues , and keep the "Your opinion doesn't matter" and "its not the communitiy's responsability" nonsense to yourself.

You say you want community feedback, but when someone speaks up with a different opinion you and Adam are very quick to jump all over that person and attack their viewpoints, kick them from channels, mark their feedback as abuse, and other nonsense.

Will refrain from giving additional feedback on CP dev as it is clear you don't really care to hear from the community, or, at least not community members who disagree with your opinions.

[droplister]

The only substantive concern here is compat: some code assumes startsWith('A') => numeric. Agree this must be updated — numeric should be A + digits only (/^A\d+$/), and named assets remain letters-only, so no collisions. That’s why an activation block + lead time + infra checklist matters.

[Jpja]

I support introducing named assets that begin with A.

Considerations
All assets have a numerical ID (if below a threshold around 1e17 == named, if above == numerical, upper hard limit ~1.84e19, special cases BTC == 0, XCP == 1).

The ID is essential because all onchain Counterparty messages use the ID only (not the name).

Through a simple formula you get from ID to name and back.

The formula name<->ID assumes A=0, B=1, ... Z=25. Because A is zero, APPLE would get the same ID as PPLE. Similarly AALBORG equals LBORG. Therefore names cannot begin with A.

Fix

1. Keep the current formula and ID range for all named assets that do not begin with A.
2. Introduce a new formula and reserve a range for A-names.

Functions in JS:

<!DOCTYPE html>
<html>
  <head>
    <script>

      const k = BigInt(1.82e19); //Space reserved for A-names begins with k+1
      const b27_digits = ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'; //Position 0 is " " to allow names to begin with A

      function a_asset_id_b27(asset_name) {
        let name_array = asset_name.split("");
        let n_bigint = BigInt(0);
        for (i = 0; i < name_array.length; i++) { 
          n_bigint *= BigInt(27);
          n_bigint += BigInt(b27_digits.indexOf(name_array[i]));
        }
        n_bigint += k;
        return n_bigint.toString();
      }

      function a_asset_name_b27(id) {
        let n = BigInt(id);
        let name = '';
        n -= k;
        do {
          let mod = n % 27n;
          name = b27_digits[mod] + name;
          n -= mod;
          n /= 27n;
        } while (n > 0);
        return name;
      }

      //Test A-names
      /* - A's ID is k+1 (relevant if we allow 1-letter names)
         - Sanity check: name is converted to ID, then back to name    
         - AZZZZZZZZZZZ has highest possible ID for 12-letter names
         - Note the full range needed for A-names is relatively small.
      */
      let names = ['A', 'AAAA', 'AALBORG', 'AZZZZZZZZZZZ'];
      for (const name of names) {
        document.write(a_asset_name_b27(a_asset_id_b27(name)) + " " + a_asset_id_b27(name) + "<br>");
      }
     /*A  18200000000000000001
       AAAA  18200000000000020440
       AALBORG  18200000000408197482
       AZZZZZZZZZZZ  18211118121133111045 
     */

    </script>
  </head>
</html>

Quirks

• This will eat up a tiny range currently used by numerical assets, eg. [18200000000000000001, 18211118121133111045].
• By definition new issuances in this range will become A-names
• If an issuance in the A-range converts to a name that do not start with A or it contains space(s) -> invalid.
• I believe it is possible to find a range with no existing numerical assets.
• If not, then what to do with old numerical assets within this range? I guess we need to hardcode exceptions for these so they remain numerical.

[davestaxcp]

@adamkrellenstein what do you think of these considerations and presented fix

[adamkrellenstein]

Yeah seems 100% reasonable and very easy to do.

[Cornholio-the-Great]

With regards to JP's final two points, someone could potentially snipe or try to grief this upgrade if the ID range is known ahead of time. Even if the range is not known, it'd take around 3,000 transactions to spoil all of the ranges. This should be taken into account when considering the hardcoded exceptions and setting a range.

[Cornholio-the-Great]

I don't think there are any assets registered with an X or some other substitute in front of the A that carries any significant value that would be harmed by this. All of those assets are essentially worthless and will continue to be indefinitely. For example, 1A6tnDeFF5jBYPBCUWVkvje41bUay7tDdc had created 51 assets that begin with XA, and I do not see any way that they are winning or losing anything today by this change.

Elon changing twitter to X is the most positive outcome for these assets, and there might be a handful of them that has potential value as a result from that new major brand. Anyone who bothered to speculate on XA assets can count their blessings that they might be able to scrounge a few sats back.

[adamkrellenstein]

ooh good point

[arwyn6969]

I just wanted to say that when I started this, I hadn’t done any prior research into the XA assets — it only came up in conversation. My intention was admittedly quite selfish: I simply wanted to include my own name in the asset tokens.
That said, I’d be genuinely happy if this ends up bringing even a bit more attention to Counterparty, even if only for a short while.
It was never my intention to cause any trouble for those who have already collected assets with the X prefix. Having been on the receiving end of similar situations in my own crypto journey, I’ve come to see that kind of thing as part of the speculation game.
I do believe there’s real potential for these XA assets to become even more special now, thanks to the lore that’s developed around the update. After all, we’re the ones who get to write our own stories, right?
For my part, I’m happy to vote in favour. At the same time, I know there are others in this conversation who may have strong thoughts on implementation, so I’ll leave my input here.
Thanks, and I’m sorry for any inconvenience I may have caused.

[aqua-019]

Very much so in favor of this implementation - as a user with a name starting with "A" - having the subasset 'quatic.xcp' or 'quaticmane.xcp' was demoralizing lmao -> thank you arwyn6969 -> publicly voicing support given technical possiblity

aquamaxxxing this proposal