Delegating KYC For Tokens #160
Replies: 2 comments
-
Delegating KYC For Tokens
AbstractThis HIP proposes an extension to the HTS mechanism by which the KYC status of a given Hedera account for a given HTS token can be indicated. Rather than actively managing the KYC status of accounts (using their own KYC key to set the KYC flag on an account [1, 2]), a token admin can delegate that burden and responsibility to the admin of some other token. If and when the admin of that delegatee token sets the KYC status of a given account to 'true', the delegator token effectively inherits that status. Note: HTS uses 'KYC' as a shorthand for some sort of approval process that Hedera accounts must undergo before trading in a token and not specifically the 'Know Your Customer' interpretation of the financial world. This HIP allows that interpretation and should not be read as an indication of Calaxy's plans/requirements for social tokens, NFTs, or otherwise - but rather functionality the Calaxy team believes to be valuable for the Hedera ecosystem. MotivitationWhen creating (or subsequently modifying if the token is not immutable) a token on HTS, an admin can optionally stipulate a KYC key. If such a key is stipulated, then individual Hedera accounts will only be able to send or receive that token if that account's KYC flag for that token has been set to true. The current model is that the KYC status for a given Hedera account for different tokens is independent, that is, the admin of each different token is expected to separately manage the KYC status of each account for their own token. This HIP proposes that, for a given Hedera account, one token would be able to effectively inherit the KYC status of another token and so remove from the delegator token the burden of actively managing KYC status for their token - delegating that management to another token's admin. RationaleThe current model of each token managing KYC status for a given Hedera account separately implies:
The above barriers might inhibit HTS adoption. SpecificationWhen creating or modifying a token, admins can optionally stipulate a 'KYCTarget' parameter with a value of an existing token identifier. If a token delegates KYC status to another token, the delegator token MUST not have its own KYC key. If a token delegates KYC status to another token, the delegatee token MUST have a KYC key. If a token delegates KYC status to another token, Hedera nodes MUST interpret the KYC status of the delegator token as identical to that of the delgatee token. If a token delegates KYC status to another token, and that other token is subsequently deleted, then the effect is equivalent to deletion of the first token's KYC key. Backwards CompatibilityThere are no known backwards compatibility considerations that would impact implementation. All previously created tokens would retain their existing KYC configurations, and those enabled with controlled mutability[3] (i.e. admin keys) could update to stipulate a KYCTarget to delegate KYC management to. Security ImplicationsSecurity implications are generally restricted to application-layer considerations, such as - what if you delegate KYC to an entity who then improperly manages their own process(es)? By definition, when delegating the "KYCTarget", a token issuer is delegating their own "KYC Key" security/management to another entity. Thus application developers would want to ensure they have a good relationship, fallback considerations, etc., when choosing a delegatee. How to Teach ThisInstead of each application developer having to stand up a sufficient verification system, they can "piggyback" onto others. For example, if a Hedera Governing Council member or other large enterprise offered a token with a KYC key (implying an underlying enterprise grade identity verification system), other projects could inherit (e.g. piggyback on) the GC members presumably comprehensive identity verification for their own token. Reference ImplementationTBD Rejected IdeasN/A Open IssuesIs it a concern that a token might not wish to have their KYC check leveraged by other tokens? Perhaps the lawyers might perceive a liability? Should a token be able to designate itself as 'KYCDoNotTarget'? References |
Beta Was this translation helpful? Give feedback.
-
|
Of course, relying merely on some other token's KYC flag on a particular Hedera account does not provide to the first token the actual details, e.g. the account owner's identity details. Consequently, this model may not be appropriate for all use cases. It would be most applicable to scenarios where 1) a number of tokens are 'federated' and there exists some other channel by which identity details would flow as necessary or 2) the KYC approval is for some simple binary check like 'over 18?'. |
Beta Was this translation helpful? Give feedback.
-
When creating (or subsequently modifying if the token is not immutable) a token on HTS, an admin can optionally stipulate a KYC key. If such a key is stipulated, then individual Hedera accounts will only be able to send or receive that token if that account's KYC flag for that token has been set to true. The current model is that the KYC status for a given Hedera account for different tokens is independent, that is, the admin of each different token is expected to separately manage the KYC status of each account for their own token.
This HIP proposes that one token would be able to delegate its own KYC management to another token. If an account had passed KYC for the second token (and had its KYC status set accordingly), the effect would be that the account effectively passed KYC for the first token.
Beta Was this translation helpful? Give feedback.
All reactions