If I create a token on Corda, how can I ensure that the issuer knows everyone's balance?

Question

I have created a token on Corda. How can I allow the issuer to know what each node's balance of the token is at any point in time?

Answer 1

Well Joel... This is a great question - doing this is often called an "internal reconciliation" in client assets and custody parlance! I'm assuming that:

• there is one issuer per token type
• this issuer is responsible for issuing and redeeming the tokens
• the issuer keeps track of how many tokens are issued!
• party nodes that wish to hold the token must register with the issuer who performs KYC and on-going transaction monitoring - this is likely a requirement in most regulatory jurisdictions. IF it is not a requirement, then there's no good way to actually know who currently holds the issuers tokens!

The issuer knows how many tokens have been issued and redeemed but doesn't know how many tokens have been sent to/from each party node and doesn't know who holds the tokens. In other words, the issuer needs to complete this equation for all nodes:

node_balance = issued - redeemed + in - out

There's a number of ways to do this each with benefits and trade-offs:

• Issuer co-signing. This is a terrible model that increases centralisation around the issuer. What is the issuer is off-line, no-one can transact etc. Not recommended.
• Write a set of flows that simply ask each node that is registered to hold the token what their balance is. This is a naive approach. Party nodes can lie about their balance but it is simple to implement. Network legal agreements could mandate party nodes to "tell the truth" or they are expelled from the business network.
• Write a set of flows that asks each node for their cash states and chains of provenance back to the issuance transaction. Perform this once a day. Using confidential identities is mandatory here as the issuer node would end up holding all the cash states and all prior transaction involving cash. The good news is that the issuer can be assured of the balances. Bad news is that this probably doesn't scale for large networks (lots of traffic at once) and I already mentioned the privacy violations. Nodes can also choose not to respond.
• Make your token expire on a rolling basis. Tokens expire on a rolling monthly basis, for example. If a token expires then it must be redeemed with the issuer for a new token. The issuer can then infer what the balance for each node was at a particular point in time. This is a useful approach as it shortens the chain of provenance (useful for scalability and privacy concerns). It does increase centralisation a little but the tokens don't all expire at the time time, so the issuer won't be overwhelmed. Downsides: if the issuer if off-line, can't redeem and spend tokens.
• Using SGX or Zero knowledge proofs or Multiparty computation. This is something we'd look to implement in the future. The issuer can be comfortable that everyone holds the "Correct" balance, I.e. no dupes / double spends but doesn't know each party node's balance.
• Require each party node to anonymously post their balance to a public bulletin board. The issuer will know if any of the balances are incorrect (too many or few tokens) but doesn't know who the posters are. This would probably have to be mandated in your business network, or something

There are a couple of other ways but I'm still figuring out how they work for the time being.

Lastly, it is worth noting that if there is no regulatory requirement to know who holds tokens and how much they have then I wouldn't bother designing this process in the first place! Remember that Corda implements controls to assure nodes that all transactions are atomic (they either happen or they don't) and that there can be no double spends of tokens. The contract code also assures nodes that no tokens can be fabricated or destroyed without the signature of the issuer. Given this is the case, even though we don't know the balance of each party, we can be assured they hold the correct balance based on the transactions they have signed and committed to the ledger.