STEEM Token Protocol (STP-1)
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
- User Account
json_metadata
: Stores each user's token balance. - Main Contract Account: Manages overall token metadata and references secondary contract accounts.
- Secondary Contract Accounts: Store detailed balances for users to manage data size limitations.
- Hash Verification: Ensures data integrity by generating and comparing hash values.
- 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
- Balance Change: The contract account updates balances in collaboration with the user.
- Hash Generation: A hash value is generated and stored based on the updated balance.
- 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:
User Transfer Request:
{ "id": "token_transfer", "json": { "from": "user1", "to": "user2", "amount": "100.0", "symbol": "UTK" } }
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" } }
- User1's
4.5 Example Workflow
User Balance Update:
{
"tokens": {
"UTK_balance": "900000.0",
"balance_hash": "correct_hash_value"
}
}
Verification Logic:
- Read
UTK_balance
andbalance_hash
from the user. - Recreate the hash using the same data.
- 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
- Set Posting Authority: Delegate posting authority from user accounts to the contract account.
- Define Token Metadata: Store token balances in user
json_metadata
. - Implement Hash Generation and Verification: Develop logic to generate and periodically verify hash values.
- 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.
Posted through the ECblog app (https://blog.etain.club)
In principle, I would very much welcome the availability of custom tokens. However, I believe that if we want to set up such a system, we should do it directly at the blockchain layer. SMTs are already quite advanced in the blockchain code. Perhaps we should direct our efforts towards finalising the implementation.
Your concept sounds good at first. But I think the details will be very difficult to realise. Especially the security against forgery is not easy. Personally, I would also be reluctant to permanently grant someone posting authorisation. As I understand it, an additional infrastructure (additional databases) is also required (e.g. for logging). That is quite a lot of effort and we don't know whether there is a need for it.
I posted some links here. @biophil created a "Proof of Concept Electronic Token (POCKET)" some years ago, and I believe it was even trading on bitshares at one point. His PoC didn't require any grant of posting authority. I agree with your point about SMTs, but only if there's a realistic chance of seeing them move forward. It's not clear to me whether that's the case, so I'm on board with exploring other solutions, too.
The links in your linked comment are very interesting. More reading material for me :-)
That would be much better. I will definitely have a look at it. I still plan to read the posts of some specific people anyway. I started with one who was once a top witness. But nothing gets lost here :-)
Maybe we should use MIST to make the follower network strength into a layer-2 blockchain parameter? 😉😉😉
I agree with what you said:
But as far as I know, no one is looking into the SMTs. I wonder why. We can start to discuss this matter.
In the meantime, I will dig more into token creation without SMTs or side-chain strategy.
Probably because it is not easy to understand the code, the idea and the financial interdependencies. A lot has to come together to finalise this effectively. But are there only two people in the world who can do that?
Right! Having multiple approaches is good.
I will follow this with interest and perhaps I can contribute a little... and I've seen that remlaps has put together some interesting older facts that might help.
💯⚜2️⃣0️⃣2️⃣4️⃣ This is a manual curation from the @tipu Curation Project.
Also your post was promoted on 🧵"X"🧵 by the account josluds
@tipu curate
Upvoted 👌 (Mana: 5/6) Get profit votes with @tipU :)
This post has been featured in the latest edition of Steem News...