Add Lockable Fractional Amounts of Fungible Tokens on Hedera #796
Conversation
Signed-off-by: Stephanie Yi <ext_stephanie.yi@toko.network>
✅ Deploy Preview for hedera-hips ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Stephanie-Yi
force-pushed
the
add-lockable-fractional-amounts
branch
from
f3f2292
to
fd8e4bd
Compare
Signed-off-by: Stephanie Yi <ext_stephanie.yi@toko.network>
Stephanie-Yi
force-pushed
the
add-lockable-fractional-amounts
branch
from
fd8e4bd
to
c77d425
Compare
| { | ||
| token_id: 0.0.123456, | ||
| balance: [ | ||
| {partition_id: 1, partition_id: 0.0.200001, balance: 10, locked: 5 }, |
There was a problem hiding this comment.
partition_id here should be partition_number
There was a problem hiding this comment.
Might be best to remove the first partition_id since the second partition_id: 0.0.200001 is identifiable enough for this partition.
| partitionKey: 0x222abc.., | ||
| partitionMoveKey: 0x333ace…, | ||
| partitions: [ | ||
| {partition_number:1, metadata: “ipfs://xxx”, partition_id: 0.0.200001}, |
There was a problem hiding this comment.
What is the purpose of partition_number? partition_id is a sufficient primary key. If partition_number is required how is it assigned (appears nowhere else in this document)?
| - If she transfers tokens from partition-3, that transfer will return an appropriate error informing her that her tokens are locked. | ||
| - To make the transfer, she will use the simple form of the current crypto transfer as the existing tokenTransferList. If she wants to transfer tokens from partition-3, she (or the SDK) queries the mirror nodes or the wallets and maps partition-3 to the TokenID of `0.0.200003` and fills that in the token transfer list of the cryptoTransfer transaction. | ||
|
|
||
| ## Specification |
There was a problem hiding this comment.
This proposed HIP has a lot of moving parts and though the wording seems clear I can’t help but think it would be more solid if it included some diagrams and/or pseudocode to make things especially concrete. There’s a lot of room for implementation fuzziness to sneak in to a big pile of words. At least if there were diagrams and/or pseudocode a contradiction between the two could be noticed and addressed - it might be either the words or the diagram/code - whereas as it stands things might slip though the implementation. And not just contradictions, but also holes.
In the same way, additional tables would be useful, e.g., which combination of parameters to APIs are valid and which are not? E.g., some of these APIs have 4 "buckets" on 2-dimensions: fungible vs non-fungible, and token-definition-id vs partition-id. It's not clear that all parameters of some of these APIs are acceptable to all 4 buckets. (And I'm not talking about the difference between "amount" and "serial#", that's clear enough.)
|
|
||
| | Partition Key? | Partition-Move-Key? | Supply-Key? | Initial Supply? | Behavior | | ||
| | -------------- | ------------------- | ----------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | N | Y | \* | \* | Acts like a normal token-def, no partition behavior | |
There was a problem hiding this comment.
Why is this line not N * * *?
…ph#796) Signed-off-by: Stephanie Yi <ext_stephanie.yi@toko.network> Signed-off-by: IvanKavaldzhiev <ivankavaldzhiev@gmail.com>
…ph#796) Signed-off-by: Stephanie Yi <ext_stephanie.yi@toko.network> Signed-off-by: Kim Rader <kim.rader@swirldslabs.com>
Description:
Related issue(s):
Fixes #
Notes for reviewer:
Checklist