Whenever we are trying to design a system that
represents the custody and exchange of goods, we find many combinations of possible owners, underlying processes and ever-changing
regulations by industry and type of asset. We have set up systems to guarantee our assets
will not be taken away without our consent. But there is a trend to make all exchanges
more fluid, even for high value items. That requirement transcends and gets to the
technology that supports these processes; on one side we have the new coming Public Ledgers,
full access and decentralized control. On the other, we have a Consortium formed, with close
oversight over real assets and tight control regarding security and information sharing.
Our system allows to integrate the advances of open public ownership and identification using
cryptography, mapping real-world workflows suited for Enterprise Applications.
Public and private Ledgers co-existing. We have the representation of a participant that
wants to do some transactions, say a purchase or a sale, with another party.
Using a settlement
company that is responsible to keep track of asset ownership in the real world. The
participant is going to sign a transaction and then put them into a vehicle; that vehicle is
going to get to the keepers node. The gatekeeper identifies and verifies the transaction,
and certifies the participant's registry Then, if everything is correct, allows it to pass
and visit the notary to execute the transaction. It also adds a certificate to grant movement of
the car inside the private network.
Finally, when reaching the notary the instruction is executed.
The route can be a one, two, or three stop path, that requires (or not) a
final stop with a notary. Now, each time the car passes through a Peer, it
issues or collects a token that keeps track of the status of the car inside that private
network. But what is in the trunk is up to us! The stops that we design the flows that we
put together. We could also have stops that links to other authorizations, even human or an
integration with other networks that are slower or without the same finality assurances.
Then we can wait longer until we make sure that all the process goes through before going
to the notary and release ownership of the asset. As you can imagine the possibilities
of these tools are endless. First you have the individuals,
the Enterprise Applications, the devices that are going
to sign these transactions. Second, we use the Polkadot extension as a
wallet to keep custody of the keys and grant access to multiple networks at the same time.
Then, we use Hedera Hashgraph as a transaction carrier of the payload, and also to manage the
single-signature or the multi-signature accounts. Corda is the one that initiates the
transactions and the workflow logic; also provides any other peer that may
or may not be part of the workflow. It also issues certificates and validates the
account inside the system are valid.
Last, Hedera provides the status of the workflow: a public
perspective of private workflows or tokens. All right. Let's see a simple demo
of how this works. In this demo, I am part of the Corda network and I will be
transferring tokens to another participant. We have one Central Bank and two commercial banks. Now, in this case I am going to be transferring
Corda tokens following the UTXO model. Since the flow is marked for finalization, the
notary reaches the transaction and triggers movements to the Hedera Network.
Let's do that! let's move from this to our counterparty; let's move 250 000 euros. This transaction went through, and out counterparty
received the movement. What you see now is I have 250 and now Hedera (via Dragonglass)
reported that movement, as well. The other bank now has updated the balance and sees
the update on Corda and the information on Hedera.
At the same time,
the Central Bank sees the update of the figures. All right. This gives of course
visibility to the other banks and the visibility of the liquidity of the
country party banks using the Hedera system. The other thing that is worth looking at here is
the management of accounts. What we have here is two accounts both of them are open with the same
holder: one of them was issued by us (that's why it has a header account and i can share it)
but the same user has another account with the Banco dei Paschi, and I have traded with this
account. That means that that account was shared, from the Counterparty Bank with us, and that is
why I have it in my books. Now for that account, I don't have all the details: I don't have the
account that that triggered a transaction nor any personal information or email or anything
of that sort.
That belongs to this second bank! Let's take a look here in this bank I have
the information and the Hedera account (that belongs to this bank) but we don't have
the second account: because this other bank (the Medici Bank) has not shared any information
with us (Paschi). And, this particular customer also has an account with a Central Bank (it could
be a Government Agency); this government agency has an account with the Central Bank but it has
not been shared with anybody else. That's it! We have put together an Extended Demo version that
is going to be in the link under the comments. Last, where are we? We
released version one in 2020, and the next step is to incorporate these
developments in a version number two. If you want to get in touch with this is my
The future will be tokenized!.