Subassets - A Proposal

Here’s a proposal on how subassets may be implemented. This is just a first draft. I’m sure there are better ways, just want to start the debate.

  • Let’s define ASSET as an alphabetic asset issued with the current naming rules,e.g. MYASSET.
  • Let’s define SUBASSET as an asset with name on format [ASSET NAME]-[EXTENSION], e.g. MYASSET-ONE.
  • To issue a SUBASSET you must be the current owner of [ASSET NAME], e.g. only the owner of MYASSET can issue MYASSET-ONE.
  • There is no XCP fee for issuing a SUBASSET.
  • The max name length for a SUBASSET is 20 characters.
  • The [EXTENSION] can exists of characters [A-Z] and be min 1 character long.

A SUBASSET is independent from its parent ASSET in every way except it shares the first part of the name and originates from the same owner. This is therefore a naming rule only.

Examples of valid names of length 20:


Consequently the owner of BBBCCCDDDEEE can make extensions of max 7 characters while the owner of BBBC can make extensions of up to 15 characters.

Advantages of introducing subassets:

  • Easier to know the owner, e.g. BOBSCOINS can issue BOBSCOINS-GLDEAGLE, BOBSCOINS-SLVEAGLE, BOBSCOINS-GLDPANDA, etc and everyone will, by just looking at the names, know that these originate from him.
  • Issuer can have a predictable name policy, e.g. a bookmaker will describe a bet through the subasset name
  • Cleaner namespace
  • Free subasset registration good in case the XCP price increases and the community cannot reach consensus on reducing the 0.5 XCP asset fee
  • Squatting of asset name will likely be reduced
  • More flexibility in use of asset names may open new user cases, e.g. alias for bitcoin address


  • A bit confusing to new users?
  • Software must upgrade to accommodate for rule change
  • Squatters of not-that-good asset names may see their assets lose value (and prime asset owners will gain since they may issue and sell subassets)

EDIT: Another great advantage of subassets is when an issuer in the future will issue assets with descriptive names. With the current system squatters can take up these names, but with subassets this would not be possible. An example of such a naming policy, copied from another thread:

The full asset name will be CBAxxxDEFyyy, CBAxxxCOVyyy, or CBAzzzxxxyyy. CBA stands for CryptoBets Season A. xxx and yyy are three letter team names. DEF means “defeats straight up.” COV means “covers the spread against.” And zzz is either OVR or UNR, which means the token is a bet on the total score.

EDIT 2: Set max length to 20. Subassets and numeric assets will have the same max length.

EDIT 3: Join [ASSET NAME] and [EXTENSION] with a dash ("-"). A dash makes it clearer that this is a name.

The naming convention for say the asset DIRT would make more sense to web users if it followed the same convention, so BUY.DIRT rather than DIRT.BUY

I think supporting subasset issuances is a good idea. Here are my thoughts on how it should be structured.

  1. Asset hierarchy structure should be similar to domain name system

    • In the domain name system we have Top Level Domains (TLDs) like .COM and .NET
    • In the asset name system we should have the ASSET act similar to the TLD
  2. Subassets should be alphabetical in nature and follow same naming conventions/rules as existing assets

    • 4-12 uppercase characters
    • Cannot start with A (though I imagine we could remove this limitation for subassets)
    • No numeric subassets (temporary/numeric assets already supported)
  3. Should be asset issuance fee for SUBASSETS similar to anti-spam registration fee

    • ASSET registration fee stay same (0.5 XCP)
    • SUBASSET registration fee could cost a bit less (0.25 XCP)

I think asset.subasset is preferable. I don’t see assets as domain names or call-to-action phrases.


Assets are things that have value. We give them names and claim ownership over them.

Buy.Dirt is an asset name that conveys an action or the capability to perform an action.

I agree with that, but visually it’s easier to inspect it as DIRT.BUY. If it was used for name resolution, the Web approach would be better.

I think that makes it harder to read. Most people read and write from left to right.
For domains, you type from left, and .com is (still) the assumed extension, but here there’s no assumed extension (or asset), you really should read from the top level.

If the reverse order was used, someone could end up buying (or selling) a wrong asset. In fact I’m sure people will try to create assets with “opposite” names to confuse buyers. Say, GOLD.COIN normally goes for $1,100 and a scammer manages to sell his COIN.GOLD for 2.9 BTC on the DEx because the buyer got confused and the price seemed “in the expected range”.

Yeah, I’m ok with either way asset.subasset or subasset.asset… Following domain naming conventions seems like the logical approach to take, but if consensus is asset.subasset is preferred that is not a big issue for me;)

Edit: This approach to implementation seems pretty clean.

I posted about this last year as Token Trees Token Trees (sub-tokens) and was reminded of @PhantomPhreak’s opinion from March 2014 bitcointalk post


I know that the comparison is not a sure thing, but it is worth considering.

Domains have three levels:
^ sub ^domain ^ top-level

What are the “qualities” of each level?

  • Sub-domains: Not in the zone-file. Can vanish any-time. Defined by a Server.
  • Domain: In the zone-file. Will be deleted, if not renewed every year by a Registrar.
  • Top-level: Has a zone-file. Zone-file is managed by a Registry which gives Registrars the rights to register new domain names. To my knowledge no top-level has ever gone defunct or disappeared. There’s even a .su (Soviet Union) still.

In the current setup, Counterparty is basically the Registry-Registrar for “top-level” Assets.

If we allow for Subassets, Asset owners will become like a Registry-Registrar for their Asset AND they could allow people to act as Registrars through API calls.

This may be desirable, however, Subassets would never expire or delete, they’d persist.

This could be really bad, really fast. It seems like this change would blow up the namespace.

There are around 300 million domains and around 1500 top-level domains. This change would be like creating infinite top-level domains. We’d start with 40k or so. Most of the internet lives on just one: dot-com.

I can also see issues around transferring ownership of a Subasset. Can I give someone ownership of a Subasset and maintain ownership of the Asset? Can I sell the Asset, but keep the Subassets?

I can also see animosity that might occur between different Subasset owners, if they don’t like what another owner is doing on the same Asset name-space. Or if they aren’t happy with the Asset owner and how they handle themselves.

The current system, in my opinion, is way better than this can of worms. And it would require all these great projects (which aren’t so numerous) to implement code changes.

Is the cost-benefit there?

If this idea does get consensus. For the love of god, don’t make it free to issue sub-assets. Make it like 10 XCP. Or, make it 100 XCP to register an Asset. Something!

IMO - This wouldn’t create a cleaner namespace. And it would moon asset squatting.

I mean, go ahead, I’ll setup shop as a Registry-Registrar, but I don’t think that’s what we want in Counterparty. As a Registry-Registrar of my Asset, I can deny registrations, require information, and begin to centralize the system around my Asset extension.

This would also likely result in negative perception of Counterparty because you’d have people setup shop to re-sell subassets at whatever price they wanted. The protocol price pretty much wouldn’t matter because only I can issue the sub-asset. So, I’m free to charge whatever I like on top of it.

It would look a lot like pre-mining vs. the current setup where squatting is more of a securing of the good tokens for the best use.


These are legit concerns. My current opinion is based more on where I personally think the CP platform is and will be and the most common use cases for assets/tokens going forward.

A Counterparty subasset system is a very interesting thought experiment. I’d like to see some variation of it exist and it could vitalize the platform, or it could make things messier.

I don’t think subassets could be used for every single use case that one can think up. Trying to implement it in a way that is maximizing flexibility will likely result in more negative outcomes. So I propose a simpler approach that would minimize or avoid entirely some of the concerns voiced thus far.

I prefer SUBASSET.ASSET but i’ll save further thoughts on that for later (another post maybe).

I think from the get-go, their needs to be some limitations and requirements before a subasset can even exist on an asset name.

  • The asset should be clean. Defining what this means can be another discussion but generally, a clean asset is one that has not truly been used for anything. The token issuance is small and no or few transactions. This is as opposed to an asset that has already been used for a project (i.e. LTBCOIN, SWARM) or just massively spread of tokens for experimentation and non-serious use (i.e. HATE, DIRT). This will immediately invalidate many assets and will annoy those asset owners, but I think it’s the right approach.

  • The asset must be delegated as a namespace asset and is no longer able to function as a native asset. This means the asset must be locked and probably all tokens issued burned if possible. Again, this becomes an issue where only unused assets qualify. Might not be popular among some asset owners but their are benefits to doing this and if asset owners who want subassets but dont qualify under these proposed rules, they can always buy/create another asset that could fill their needs. The benefits, I think, outweigh the small amount of limiting cases.

  • In addition to being locked and tokenless, the asset cannot be transferred to a new owner without additional multisig-esque process in place. This may not be necessary but it came to mind.

  • The ASSET Owner can curate (approve/reject) any SUBASSET request. This would be a great use case for a simple smart script/config/contract that could be setup to either allow-all, disallow-all, owner-review etc. This would be the ONLY power an ASSET Owner has (as a Gatekeeper). If a subasset is created by another user and approved, the subasset is just like any other asset and NOT controlled by the ASSET Owner, it is only related to the “Namespace”. ASSET Owner could close and open “registrations” via this config script or wallet settings.

  • Subassets can never have its own subassets. It’s a one-level deep system only.

I’ve not put too much thought into any of this and it might show here :wink: I’m just contributing some thoughts that are coming to mind in the chat room so logging it here. Look forward to other opinions.

1 Like

I feel that the subasset registrations should NOT be free. There should be a minimal charge of perhaps 0.2 XCP per subasset.

I really like the thought process behind Sull’s suggestions. Many of those ideas have been vetted through the Domain process, which is a mature platform at this point. While I am not particularly excited about the sub-asset idea in general, I can see that there is a need beyond my narrow interest.

There is a definite need for limits, otherwise existing token endeavors could be harmed. I think Sull covers most of them very succinctly. Using the following example, MCDONALDS.WIFI or WIFI.MCDONALDS, it has a definite impact on possible future values depending on wether I own WIFI or MCDONALDS. If I own both, then I’m in a particularly beneficial spot. However, without common sense limits such as the suggested namespace or native designation, some asset registrars/owners are going to be unhappy and users could become confused and be less likely to adopt.

Related to this, in Slack there’s been a proposal to add a condition to lock issuance on the asset so that it and subassets cannot be used for anything but namespace.

The more I read about possible problems, the more I think it may be a better good idea to consider a separate type of tokens for namespace and leave the asset namespace flat.
My understanding was that subassets would be used by the issuer to consolidate their various assets under one asset name, but I see some want to use it for TLD-type of sub-domain hosting which is more of a branding/namespace type of use and that’s why I think in case all subassets aren’t owned by the same owner and asset issuance locked, I’d suggest to use a new namespace type of token.

I think there should be a fee. Subassets would consume space and resources in the CP database. Someone ought to pay for that.

Lots of interesting replies. At this point maybe we should better simplify the discussion to these three alternatives.

  1. Keep the asset system as is. If it ain’t broken, don’t fix it.
  2. Introduce subassets. If this is the best option we can discuss details later.
  3. Make an (unofficial?) layer for wallets and explorers. A format for info/hash in the description field can serve as the asset name, maybe for numeric assets.

I think sticking to the current system is not a bad option. We will never run out of names. There are more than 100,000,000 .com domains and you can still find okay unregistered domains if you’re not willing to pay for one. CP has about 30,000 alphabetic assets.

The main reason I suggest subassets is because some issuers issue several assets (e.g. Spells of Genesis) and with subassets they can have a name policy on format “ASSET-x”. Being able to verify an asset only from its name adds value to users. Another example is a bookmaker. He issues assets whose names fully describe the underlying bets. Without subassets trolls/squatters can deliberately pre-register assets and cause harm.

If there is a clever way to achieve the same with a meta-layer, then maybe that’s the way to go?

Does anyone in this discussion have a use case for subassets that they have bumped into yet? Does this solve a real world problem for anyone here?

I like the discussion here because it helps us think through the ramifications. But if it isn’t a real world problem yet, I suggest we wait on this until we know the needs of the real world problem we are trying to solve.

So, I’m in favor of 1 for now.

1 Like

It’s not a real world problem… because CP isn’t a real world platform (yet). It’s too niche to think too hard on whether a feature solves real world problems. I think we can discuss this issue in the context of general namespace/identity concepts that have existed prior and base some decisions on that. We can also look at some current trends and use cases, such as SoG, and clearly see how sub-assets could improve usability and organization of token based systems.

On a more casual level, I generally think that subassets would pump some life into the community/platform. As great as it is, I think this would be a deep step into the “naming/identity on the blockchain” space where other projects are starting to find momentum. So it’s an easy way to become even more relevant and functionally diversified.

1 Like

I mentioned over in slack and skype the rather crazy notion of alphabetic subassets on numeric assets. This would essentially allow, depending on implementation, anyone to own any name, over and over again. WTF? Wallets could hide the numeric asset and only show subasset and owner address info.

This would destroy the unique name system that is in place and bring it closer to how other platforms work (NXT, OpenAssets/CC, Omni non-unique names). I personally like both approaches and have leaned more towards non-unique as being the right approach but I also like scarcity despite “squatting” issues. Long time ago, I used to talk more on this topic back when DogeParty launched.

So I bring this up so the proposal can include or exclude subassets on numeric asset names. It’s not something that has been brought up yet I dont think. The easy answer here is NO! Preserve some scarcity! But am curious what others might think.

Lastly, I put some more thought into the issue and I don’t think the protocol should bother with the additional rules that I proposed earlier (Locked and Tokenless Namespace Asset Delegations). I still think that would be smart, but would likely hinder the feature from getting added sooner than later and in reality, the rules could be instead published as consumer/business warnings and guidelines to making good decisions about subasset usage.

1 Like

If possible, could the sub asset be used as a singular proof of existence? I dropped a document in a SHA256 generator. Lets say it represents a Gold Bar and I want to register the bar of gold via a service that does just that. I use a GOLDBAR token and am allowed, for a small fee to append my hash as a subset.


While I understand this is currently impossible and seems a bit ridiculous as I type. Maybe one of you know of a more elegant method to use a subasset in this manner? Is it possible to shorten that hash and make it compliant with CP as shortened URL’s are used today, or make CP sub-assets compatible to that type of info as a suffix?

I’m guessing the token or subset token info could contain the hash and a link could be employed to point to the location of the proof of ownership/existence? As you may be able to tell, I’m a lay-person, trying to grasp the concept with 10 thumbs. Hopefully this makes some sense.

Subasset is currently not possible, but you can issue a numeric asset. You will need to convert the hash to a numeric representation and issue the numeric asset with one indivisible share.

An alternative/workaround to sub-assets; wallet icons to display certain properties.

1 Like

Yes, it’s a real world problem. In Brazil assets in the brazilian stock exchange (Bovespa) are of two types: Preferential and Ordinary. Doesn’t matter explain these two types right now, but they exist. Below is a example:

Enterprise: Petrobrás (PETR)
Ordinary: PETR3
Preferential: PETR4

There are hundreds of other “subassets” for derivatives (call and put options):

Series		Strike Price	Expiration
PETRA22	E	4.25	        01/18/2016
PETRA5		5.00	        01/18/2016
PETRA56		5.60	        01/18/2016
PETRA57	E	5.70	        01/18/2016
PETRA28		5.80	        01/18/2016
PETRA60		6.00	        01/18/2016
PETRA62		6.20	        01/18/2016

and go on…