I have devised a protocol to create and manage custom tokens on the STEEM blockchain. The initial version of the whitepaper has been created.
The key part is that the balance of a token are stored in json_metadata of a user's account and the balances are managed by hierarchal contract accounts.

If you have any ideas and thoughts, please share them. Let's improve this protocol together.

---

STEEM Token Protocol (STP-1) Whitepaper

Abstract

STP-1 is a standard protocol designed to allow users on the STEEM blockchain to create and manage tokens securely and efficiently. This protocol leverages user json_metadata for token balance management and ensures data integrity through hash verification. A hierarchical structure using main and secondary contract accounts is employed to ensure scalability.

1. Introduction

1.1 Background

STEEM is a blockchain-based social media platform that rewards users for creating and curating content. Despite its robust reward system, there is an increasing demand for more flexible and customizable token solutions akin to Ethereum's ERC-20 tokens.

1.2 Objective

The objectives of STP-1 are to:

• Ensure security and decentralization in token management.
• Facilitate easy creation and transfer of tokens.
• Ensure transparent and verifiable token operations.
• Provide a scalable hierarchical structure.

2. Protocol Components

1. User Account json_metadata: Stores each user's token balance.
2. Main Contract Account: Manages overall token metadata and references secondary contract accounts.
3. Secondary Contract Accounts: Store detailed balances for users to manage data size limitations.
4. Hash Verification: Ensures data integrity by generating and comparing hash values.
5. Off-Chain Services: Optional services for validation and monitoring.

3. Hierarchical Account Structure

3.1 Main Contract Account

• Manages overall token metadata and references secondary accounts.
• Example json_metadata:

  {
    "tokens": {
      "UTK": {
        "issuer": "contract_account",
        "total_supply": "1000000.0",
        "decimals": "2",
        "secondary_accounts": ["sec_account1", "sec_account2"]
      }
    }
  }
  

3.2 Secondary Contract Accounts

• Store detailed user balances.
• Example json_metadata:

  {
    "UTK_balances": {
      "user1": "50000.0",
      "user2": "200000.0"
    }
  }
  

3.3 Data Size Limitation

• json_metadata has a size limit of 8192 bytes.
• Main and secondary accounts are used to efficiently distribute and store data.

4. Token Management

4.1 Token Balance Storage

• Users store their token balances in their own json_metadata.

4.2 Posting Authority Delegation

• Users delegate posting authority to the contract account to allow it to update json_metadata.

4.3 Balance Update Process

1. Balance Change: The contract account updates balances in collaboration with the user.
2. Hash Generation: A hash value is generated and stored based on the updated balance.
3. Verification: Periodic hash comparisons ensure integrity.

4.4 Token Transfer Transaction

Token transfers are executed using the custom_json operation. Users update their balances, and the contract account verifies and updates the recipient's balance.

Token Transfer Example:

1. User Transfer Request:

   {
     "id": "token_transfer",
     "json": {
       "from": "user1",
       "to": "user2",
       "amount": "100.0",
       "symbol": "UTK"
     }
   }
   

2. Contract Account Balance Update:

   • User1's json_metadata:

     {
       "tokens": {
         "UTK_balance": "899900.0",
         "balance_hash": "new_hash_value"
       }
     }
     

   • User2's json_metadata:

     {
       "tokens": {
         "UTK_balance": "100100.0",
         "balance_hash": "new_hash_value"
       }
     }
     

4.5 Example Workflow

User Balance Update:

{
  "tokens": {
    "UTK_balance": "900000.0",
    "balance_hash": "correct_hash_value"
  }
}

Verification Logic:

1. Read UTK_balance and balance_hash from the user.
2. Recreate the hash using the same data.
3. Compare both hashes:
   • Match: Continue as normal.
   • Mismatch: Log discrepancy, alert the user, and investigate.

5. Security and Verification

5.1 Security Measures

• Posting Key Management: Users should only delegate posting authority to trusted contract accounts.
• Hash Algorithm: Use strong hash algorithms to prevent collisions.

5.2 Verification Procedure

• Periodic Verification: Contract account or off-chain services regularly verify hash values.
• Log Records: All transactions are logged for traceability.

6. Handling Violations

6.1 User-Initiated Changes

• Detected through hash mismatch.
• Log the event, alert the user, and restore balance.

6.2 Contract Account Hacking

• Regular verification detects unauthorized changes.
• Log the event, track changes, and restore correct state.

7. Implementation Guidelines

7.1 Developer Instructions

1. Set Posting Authority: Delegate posting authority from user accounts to the contract account.
2. Define Token Metadata: Store token balances in user json_metadata.
3. Implement Hash Generation and Verification: Develop logic to generate and periodically verify hash values.
4. Set Up Main and Secondary Accounts: Use a hierarchical structure for efficient data storage.

7.2 Community Contributions

• Propose improvements and develop tools.
• Share implementation examples and provide feedback.

8. Conclusion

STP-1 is a standard protocol for securely creating and managing tokens on the STEEM blockchain. By leveraging json_metadata and hash verification, it ensures data integrity and decentralization. This protocol enhances transparency and security, allowing developers and users to freely create and manage tokens.

---

cc.
@pennsif
@steemcurator01

Posted through the ECblog app (https://blog.etain.club)