GAAP, Compliance & "Pattern Positive" conventions

[robertdavid010]

Summary

TLDR:

We don't use "coin" terminology because:
a: we are not tracking actual coins (this is potentially non-compliant, and a design anti-pattern)
b: terminology & conventions should be application agnostic (as is expected with an SDK).
Therefore we should organize conventions for asset "tracking" on chain as best to address this.

Problem Definition

It has been known in the blockchain/crypto space that the mis-branding and conceptual anti-pattern of describing raw/agnostic value measures in transactional ledgers as "real" asset types (to give appearance of value through inappropriate conflation between these abstract value measures and unattested real-life assets) as in the mis-use of the term "Coin", is in-congruent with General Account Principles, as well as being anti-pattern to the fundamentals of data-modelling and application design. In all of these cases we are to represent data with conventions that as accurately as possible describe what they are in the use case of the application.

Proposal

As such a simple removal of terminology mis-representing specific applications of blockchain technology (the "coin" term) and replacing with application agnostic variation within the SDK for compliance with GAAP, being pattern-positive in the development of applications, and therefore having ability to be better communicated for compliance and regulatory reasons in the use of the SDK for real world financial applications (primary use case presented for blockchain/cosmos).

1. in x/auth replace instances of "coins" with "balance"
2. in x/bank replace Coin struct (and other uses of the convention) with a corresponding application agnostic convention:
   • SimpleAsset or
   • BasicAsset or
   • BaseAsset
3. Identify other areas of the SDK to replace "coin" convention
4. Update documentation & messaging to reflect the changes

Summation:

Defining values in an application framework for financial ledgers in agnostic terms, as well as in the most simple and straightforward terms makes the SDK more compliant, and implements stronger patterns, but also allows namespace for further plugins/modules to define more complex assets. Also at this point in time a potentially "breaking" change of this type has least impact possible.

Benefit:

This can help in the adoption of the SDK by:

1. Easier onboarding & adoption by existing fin-tech developers, engineers, and projects
2. Direct use of SDK conventions lowers design/messaging costs for projects
3. Improved communication and understanding for business, enterprise, regulators and even end users or consumers
4. Reduced risk (even perceived) of non-compliance

Update:
Improved formatting, minor copy edits

[fedekunze]

Thanks for opening this issue @robertdavid010. I agree with 1. ideally an account should contain a balance that may not represent only Coins.

Regarding 2. I don't think we should rename Coin, we could instead create an Asset interface which Coins could comply (with functions like Get, Set, Delete). Then, bank for example could change it's behaviour to handle transfer of assets (i.e trade asset for asset).

Also, I'm not familiar with GAP and the conventions you mentioned. Could you provide some references that we could take a look into ?

I'm curious of what @sunnya97, @cwgoes , @okwme and the rest of @cosmos/cosmossdk team think on this matter

[alessio]

@robertdavid010

I appreciate and welcome your proposal most enthusiastically.

The more GAAP-compliant we are, the better we can serve our clients.

This can help in the adoption of the SDK by existing fin-tech developers, engineers, and projects, by easing communication and reducing even perceived risk.

I couldn't agree more to that. Risk perception is one of the major factors that prevent global financial institutions from adopting innovative technologies, no matters how efficient and cost-effective they could prove to be.

[alessio]

@jaekwon @zmanian

[okwme]

What about the use of the word Token? A token is just a means of representing something else, whether it is an asset or a permission or something else entirely. I always thought that's why it has been the go-to term within the Ethereum community.

[robertdavid010]

@fedekunze /agree with your point on 2.

There are certain instances where "Coin" could be an appropriate convention to represent an asset (maybe not arguable in purely the abstract, but in real terms certainly). Including it as a subset or a "type" of asset within a broader "asset framework" makes sense.

Of course there is a broader agenda to this discussion in my opinion, which is how best to support not just simple assets, but more complex assets in the future (and means combinations of simple/primary assets/methods?).

@okwme agreed that Token has been an adoption by the community at large which has been an improvement, as it is a much more agnostic term (unless you remember video game arcades). Maybe "Token" is another type of asset? Probably an asset specification scheme could be drafted to support discussion?

[okwme]

We've begun discussing the scheme around Non-Fungible Tokens here: #4046

And @fedekunze and I have been working on a draft of the module here: #4118
(We need to update the issue with some of the thoughts that have gone into the current implementation as I'm curious to general opinions about some of the choices we've made)

I've always thought of NFTs as much closer to a general case asset. The real world seems to have way more "non-fungible" assets than fungible assets. Maybe also relevant here is the connection between non-fungible assets which become fungible via fractional ownership. I've made an EIP on that category as well here: ethereum/EIPs#1634

[robertdavid010]

@okwme thanks for the links. I will get caught up on your work.

Could it be resolved that there are only 2 primitive types of assets: Fungible and Non-fungible?
Also does the combination of these two primitive asset types form most complex asset types?

[okwme]

I think there is an EIP out there somewhere trying to make a distinction between digital assets that represent physical assets and digitally native assets. That might be a useful distinction but also might already be too opinionated.

I like the way @shrugs has been discussing non-fungible tokens as "Digitally Ownable Things" or DOTs. It's a little silly sounding but also totally open as anything is a thing (lol) including objects, images, ideas, relationships, permissions, assets, attributes etc which I think should all be considered very legitimate use cases of tokenization with DLT. Fungible tokens also fit into the category of "things" with the special attribute that they are indistinguishable when grouped.

In general I think "don't fix it if it ain't broke". If it can be determined that using "coins" is broken I'd suggest going with the next most common and functional solution and at this point that seems to be "token".

[shrugs]

Agreed that the informational category hierarchy probably looks something like this:

Asset ("Digitally Owned Thing")
 |_ (technically & practically) Fungible Assets
 |_ (technically & practically) Non-Fungible Assets
 |_ (practically) Quasi-Fungible Assets

where technically is a data-model distinction (erc-20 vs erc-721) and practically is how users perceive it. "quasi-fungible assets" captures the in-between spectrum: these are things like collectible quarters: they are, at a technical level, non-fungible assets, but could be considered fungible in certain context's (at the store) and non-fungible in others (in a collection of other quarters). see also: serialized bills, bitcoin UTXOs

I'd also avoid prescribing the metaphor for "digitally-native" assets and "physically-bridged" assets (although I do prefer those terms right there 😉)

that said, imo, the fungibility property of an asset is an implementation detail—it's developer-facing. I don't find much value in talking about fungibility with normal users. The only distinction I think about around users is how these assets are displayed. If they're technically or practically fungible in a certain context, we can sum the balance and call it a day. If they're practically or technically non-fungible in a certain context, we can highlight whichever property makes them unique in that context.

Personally I use the term "digitally owned thing" as a catch-all for any digital thing I own (implication: "true" ownership on a DLT). When it comes to messaging to users, I find it much natural to have people first assume non-fungibility (i.e. nonfungible assets are the default, for the reason @okwme mentions: #4153 (comment) ) and only then introduce the 'edge' case of perfectly fungible digital things. Perfectly fungible digital things are the odd ones, imo—depending on your perspective, the physical world has 0 truly fungible assets, and the digital world has a bunch of 'practically fungible, yet non-fungible' assets (like digital dollars or UTXO coins). You only get true fungibility from a privacy-preserving mechanism that literally removes the non-fungible information from the world, and we don't have many of those around today.

Of note, I think the definition of the generic term "token"has probably trended towards specifically fungible tokens, which may not be the implication you want to encourage.

---

All of that is to say that definitions, metaphors, and naming is a hard problem, and we must first decide on who we're naming these things for. My recommendations are something like:

For users, just call everything an "asset". To communicate fungibility, use your UI to do so: fungible assets are just a line-item and the balance is summed. Non-fungible assets are displayed some other way (no best practices), but you should highlight what makes them unique. Is this a video game? Display a grid of items per-type if each item within the type is practically fungible. Show "edition" or "1 of 20" for non-fungible art. If you absolutely must use an english word to communicate the difference between a fungible asset or a non-fungible asset, you can use "unique asset" or "nifty" (a note on "nifty" below). Also, as much as I like "dots" (and it is the namesake of my own startup 😂), I don't think it's a good user-facing word for digital assets.

For developers, you should probably just go with the flow: All assets are "tokens", fungible tokens are "fungible tokens" / "FTs" and non-fungible tokens are "NFTs". You could also say that all assets are "assets", fungible assets are "tokens", and non-fungible assets are "NFT"s, which would lean into the "tokens are fungible" colloquial definition.

Just please don't ever tell a user that their token is "fungible" 🙏

---

The term "nifty" may or may not still be in the process of being trademarked by Dapper Labs, the company behind CryptoKitties: https://trademark.trademarkia.com/nifty-88046182.html

An employee at the company mentioned in a DM that they've released their claim on the trademark, but the online records don't reflect that. After I requested they announce their revocation publicly, they have yet to do so, so use "nifty" with that existential caution in mind.

[mikmik]

@okwme thanks for the links. I will get caught up on your work.
Could it be resolved that there are only 2 primitive types of assets: Fungible and Non-fungible?
Also does the combination of these two primitive asset types form most complex asset types?

Some thought about these "non-fungible assets":

• Rupert MURDOCH -> let me buy News Corp.
• Joe BLOW -> let me buy 100 shares of News Corp.
  or...
• Steve COHEN -> Let me buy "Le Rêve" by Pablo Picasso ($166.7M)
• John DOE -> Let me buy 0.000 001 token of "14 Small Electric Chairs" by Andy Warhol

Non-fungible is fractionable into fungible.

[shrugs]

re: fractional ownership, practically, non fungible assets can be owned by fungible shares, but technically that original asset is still non-fungible and the shares are fungible. So that distinction is best managed at the user-facing level, not the developer implementation level, imo

[alexanderbez]

Are we leaning towards replacing the "coin/s" nomenclature in the SDK with Token or Asset? Note, I do strongly believe the are certain places in the SDK where coin/s should still be used...at least for the time being (eg. most prominently staking).

There has been great discussion thus far on this issue and I'd hate for this to slip under the radar so to speak. I certainly think there are some modifications we can and must make to SDK type nomenclature. So let's try to narrow the scope of the discussion and derive what changes we should make and why 👍

[okwme]

Maybe it's good to point out where the nomenclature should stay coin/s and why @alexanderbez ?

[alexanderbez]

Sure! My initial intuition says anything involving staking and the underlying distribution...but maybe this could be changed too as you could have fractional assets of anything that's fungible I guess.

[robertdavid010]

@alexanderbez thanks for your feedback. To all: it seems agreed that this issue has interest, and that it also could significantly affect understanding, compliance, and adoption of Cosmos. If parties to this discussion are so motivated perhaps we could convene a live chat to organize research etc. I'm happy to host discussion on this issue.

Edit: Also seeing 2-3 of us are in Berlin, I'm able to meet in person.

[robertdavid010]

@shrugs I think that is a good start, but I would suggest also more primitive definitions.

Agreed that the informational category hierarchy probably looks something like this:

Asset ("Digitally Owned Thing")
 |_ (technically & practically) Fungible Assets
 |_ (technically & practically) Non-Fungible Assets
 |_ (practically) Quasi-Fungible Assets

Fundamentally the tracking of assets in a DB/ledger is based on accounting principles. Therefore I would look at it in accounting terms. Below are examples of possible categorical primitives and represented data-model.

A: Basic Accounts Ledger

Track numeric balances

accountID	balance
0xs0d9f8s0d...	32900000
0xf90ds9dss...	8932000

B: Basic Asset Ledger

1 Degree added complexity and simple notarization/hash&stash

accountID	asset
0xs0d9f8s0d...	{type: bicycle, brand: Schwinn, color: blue }
0xf90ds9dss...	{type: bicycle, brand: Espa, color: orange }

C: Assignable Asset Ledger

Assets are transferable to new owners

assetID	asset
0xsd0azXdlop...	{type: bmx, brand: Schwinn, color: blue, owner: 0xs0d9f8s0d... }
0xlkjf0s9dsza...	{type: racer, brand: Espa, color: orange, owner: 0xf90ds9dss... }

D: Compound Ledger

Combining and nesting the above gives all possible asset definitions: eg. Mortages

assetID	asset
0xs0d9f8s0d...	{ type: adjustable, term: 5yrs, issuer: DB, rate: 25, balance owing: 1200000 }
0xf90ds9dss...	{ type: conventional, term: 10yrs, rate: 45 issuer: BofA, balance owing: 86000 }

These primitives should satisfy the accounting of asset categories you proposed(?). However this does not take into account the distinction between "real" or "virtual" assets. Technically is the only difference is the sources of attestation to the "realness" of the asset being registered and tracked? This seems potentially an area of deeper discussion.

[robertdavid010]

As an additional point, the concept of "gas" is also misnomer. Common business & accounting terms easily accommodate the defining of work budgets and unit rates. This "used" to be admitted in the Ethereum docs I seem to recall (couple years ago now, seems like updated since then). Regardless I believe there is a lot of opportunity to improve conventions and communication, dramatically reducing the barrier to adoption of Cosmos

[robertdavid010]

Following up to add that I will probably have a go at finalizing definitions after going through a new build phase related to asset management/financial transactions. I will be happy to take lead on this issue, please let me know if I am duplicating work.

[fedekunze]

Thanks @robertdavid010 ! I'd love to see this on an ADR prior to the implementation. Let me know if you need any help

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tac0turtle]

reopen if still applicable