Is it possible, or on the roadmap, to limit the balance of a custom asset in a wallet? This would be a great feature, in that smaller transaction/balances don’t always have the same level of KYC as larger ones. In other words, if you could implement “tiered” trust lines, the more onerous kyc requirements could be delayed (making initial sign up much easier)
-
Wouldn't this be something happens before token distribution? You would know the KYC requirements associated with a given account and would know they couldn't hold more than x amount of your token. If you know that they can't hold more than a certain amount then you wouldn't distribute it to them. It seems redundant to implement this at the protocol level.– koltenCommented Nov 2, 2019 at 0:49
-
Hello, thanks for the reply. Actually, the Kyc requirements specific to money transmission apply to overall transaction sizes eg did an account send/receive more than 10k usd equivalent within a single transaction - or in aggregate across a 24 hour window. If we could control this via trustlines, it would help delay kyc (which is a big turn off for many people). Trustlines already have a concept of max tokens trusted, but it is in the wrong direction and not terribly useful...– tylercCommented Nov 6, 2019 at 0:17
1 Answer
Simple Limits
Step 1: Set the authorization required
flag for your issuing account (?), this way nobody can create a trustline for your asset without your authorization.
Step 2: Require users to set a limit when creating a trustline. That's the second parameter in the CreateTrust operation. That is the maximum amount of asset tokens that their account may hold, any transaction exceeding that value will be rejected by the network.
Step 3: Since your asset is authorization required
, you need to confirm new trustlines with the AllowTrust operation. Simply check if the limits were set correctly and approve/deny accordingly.
Granular control
If you have to enforce more specific rules, you need to check+approve/deny every single user transaction. There are two ways for this:
1) Multisignature
Require user accounts to have you as another signer for their account. Now they can't submit any transaction without you co-signing.
2) Multi operation transactions
Instead of permanently allowing trust, require your users to sandwich every payment in a set of [AllowTrust, Payment, RevokeTrust] operations. Now you also have to sign those transactions and the allowance will be atomic for that single payment operation.
SEP-8
Not sure if anyone has implemented that in a production environment yet but have a look at SEP-8, which describes a standardized way to handle your co-signing.