HCS-20: Auditable Points Standard

[HGraphPunks]

Title: "HCS-20: Auditable Points Standard"
Author(s): Patches (@tmcc_patches), R3n_ly (@r3n_ly), Ping (@hgp_ping), Turtle Moon (@TurtleMoonCC), HGraph Punks (@HGraphPunks). With help from: Kantor (@kantorcodes)
Type: Standards Track
Category: Application
Created: 1/10/2024

Abstract

The HCS-20 standard proposes a system for tracking the "points" or movements of any assets on the Hedera network, utilizing HCS topic IDs for documenting movements and actions through HCS transactions.

Motivation

This standard aims to facilitate the easy creation, transfer, and management of digital assets like loyalty points or gaming high scores on the Hedera network. Its efficiency and flexibility make it ideal for a wide range of applications.

Deploy Point Contract

{
  "p": "hcs-20",
  "op": "deploy",
  "name": "point_name",
  "tick": "unique_point_identifier",
  "max": "max_supply",
  "lim": "optional_limit_of_mint_per_transaction",
  "metadata": "optional_metadata",
  "m": "optional_memo"
}

Attributes Table:

Key	Required	Description
p	Yes	Protocol identifier, specifies HCS-20
op	Yes	Operation type, here it's 'deploy'
name	Yes	Name of the point, describes the asset being created
tick	Yes	Unique identifier for the point, akin to a ticker symbol
max	Yes	Maximum supply of the point, sets the upper limit
lim	No	Limit per transaction for minting, optional
metadata	No	Optional additional data related to the point
m	No	Optional additional memo related to the point

Mint Point

{
  "p": "hcs-20",
  "op": "mint",
  "tick": "unique_point_identifier",
  "amt": "number_of_points",
  "to": "recipient_hedera_address",
  "m": "optional_memo"
}

Attributes Table:

Key	Required	Description
p	Yes	Protocol identifier, specifies HCS-20
op	Yes	Operation type, here it's 'mint'
tick	Yes	Unique identifier of the point to be minted
amt	Yes	Amount of points to mint
to	Yes	Address of the recipient receiving the minted points
m	No	Optional additional memo related to the point

Burn Point

{
  "p": "hcs-20",
  "op": "burn",
  "tick": "unique_point_identifier",
  "amt": "number_of_points",
  "from": "holder_hedera_address",
  "m": "optional_memo"
}

Attributes Table:

Key	Required	Description
p	Yes	Protocol identifier, specifies HCS-20
op	Yes	Operation type, here it's 'burn'
tick	Yes	Unique identifier of the point to be burned
amt	Yes	Amount of points to burn
from	Yes	Address of the holder from whom points are being burned
m	No	Optional additional memo related to the point

Transfer Point

{
  "p": "hcs-20",
  "op": "transfer",
  "tick": "unique_point_identifier",
  "amt": "number_of_points",
  "from": "sender_hedera_address",
  "to": "recipient_hedera_address",
  "m": "optional_memo"
}

Attributes Table:

Key	Required	Description
p	Yes	Protocol identifier, specifies HCS-20
op	Yes	Operation type, here it's 'transfer'
tick	Yes	Unique identifier of the point to be transferred
amt	Yes	Amount of points to transfer
from	Yes	Address of the sender
to	Yes	Address of the recipient
m	No	Optional additional memo related to the point

Each of these tables are meant to provide a clear breakdown of the key attributes necessary for the respective operations in the HCS-20 standard, along with whether they are required and a brief description of their purpose. This format follows the approach seen in the BRC-20 documentation, ensuring clarity and comprehensiveness.

Rationale:
The HCS-20 standard emerges as a solution to a pressing problem in the web2 and web3 world: the need for a transparent, auditable, and versatile control system for points. Its primary benefits include:

Public Audit-ability:

• Creates audit log for transparency in point transactions.

No LP or Value Expectation Issues:

• Streamlines operations without liquidity, compliance, or value complications. Great for loyalty points, gaming points, etc.

Control Flexibility:

• If in private mode, it offers the creator the power to oversee all point movements.

Each function in this specification is designed to ensure a versatile, and user-friendly environment for digital assets on the Hedera network, focusing on the needs of loyalty programs and similar applications. There is no option for "holders" to use a liquidity pool as it's not a fungible token, alleviating potential tax and legal issues.

Points also don't need association, nor account creation to function, providing a more simplistic approach to document community worth without needing FT or NFT infrastructure.

There are two major ways to use this standard.

Private
✅ Submit Key

A topic ID with a submit key allows control of all data posted to that topic. This is great for most use cases like gaming, leaderboard points, loyalty points, etc.

Valid transaction indexing note:
Indexers of topic Ids with submit keys shouldn't require the payer account id to be the same as the one moving balances. Since the submit key requirement implies only authorized parties should have write access to move funds, all transfer transactions written are authorized.

Public
❌ No Submit Key

A topic ID with no submit key allows anyone to sign and write transaction openly to the public topic Id. Creators can make their own topic ids, or can use the proposed main topic id.

Benefits of using the main public topic Id is to give access to a central location of all inscriptions for HCS-20 public points where indexers don't need to index multiple topic Ids for balances.

Valid transaction indexing note:
Indexing valid balances also includes checking if the payer account id is the same as the transfer of balance out of an account. If payer account is different than the account having points removed, it's indexed as a failed transaction

Backward Compatibility

The HCS-20 is designed to be compatible with existing Hedera standards, ensuring smooth integration into the current ecosystem.

Security Considerations

None, this is only a JSON standard that should not affect security of any technical system.

Reference Implementation

https://hcs20.com
https://hashscan.io/mainnet/topic/0.0.4350190