As the author mentioned, shareholder voting is ripe for disruption with a blockchain based system. What is the market size at stake for the middle-man companies?
The author also mentioned -you know- building a solution on 1980's-era tech, namely a single database of actual (rather than proxy) shareholders and contact information/voting instructions/other useful info:
"You could just, you know, build a big database of who owns shares, and transfer shares on that database, and not rely on a system in which people own shares in brokers' databases and brokers own shares in DTC's database and DTC owns shares in companies' (transfer agents') databases. The big database could send out voting instructions directly to the shareholders, cutting back on the outsourcing. You could build a new system, from the ground up, corresponding to the actual practices of finance rather than to the archaisms that they're built on." [0]
No need to go all blockchain and shit, just consolidate the mess of systems into a single well-designed and well thought-out one.
[0] That 'graph is -incidentally- the 'graph that immediately precedes the one that mentions The Blockchain(TM).
In countries that aren't the US, things tend to be somewhat closer to this situation... Here in Australia, for example we've basically completely abolished stock certificates for publicly traded companies, and we don't have any equivalent of DTC as far as I am aware. Nominee holdings still exist, but it's significantly less common than in the US, and it's significantly more common for shareholders to be directly registered.
When reading that, it's important to recognize it was compiled by Computershare, a transfer agent, who in some ways compete with DTC. Computershare has virtual monopolies in that business globally.
I don't think they are wrong, but they aren't a disinterested party.
So what I imagine when we talk about a single database is just some mapping of stock shares to owner. So to keep track of who owns what share, when some shares gets transferred you just update each row accordingly. (Imagine a stock with 10 total shares and X sells to Y shares #1, #2, #3, you'd just update the table and set owner=Y where share id is in (1, 2, 3))
But for such important financial data you don't want to just update your table and throw away your history. You'd like to also keep a record of what changes occurred. Maybe you'd like to audit your database, and find out the path of ownership from which a current owner obtained their shares. Maybe you'd like to make your history immutable, so as to not have headaches later on trying to validate the current state, or to discourage tampering with the database.
So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains. There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto), but I think the author was going for the former meaning.
That is to say, you can implement a blockchain and still be using a single well-designed and well thought-out database.
> So what I imagine when we talk about a single database is just some mapping of stock shares to owner.
Mmhmm. Keep simple things as simple as possible.
> So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains.
Well, if that's what a "blockchain" is, then git [0] was doing blockchains way before they were cool.
> There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto)
I can see not having a distributed ledger, but if you eject the cryptographic part of it then you don't get any of the tamper resistance. Without that, all you have is a linked list. And -as we all know- "linked list" is a much less sexy phrase than "blockchain".
[0] And -if we drop the cryptographically verifiable history part- pretty much every VCS ever.
> now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like
A ledger! A concept which goes back to at least the Sumerians, and can now be efficiently implemented with a variety of technologies - databases, version-control systems, log-structured messaging systems, even good old fashioned files.
> what we talk about when we talk about blockchains.
Er, no. A blockchain is specifically a ledger where the entries are certified by a distributed proof-of-work mechanism. A blockchain is useful where the parties contributing to the ledger don't trust each other, have no way to establish trust with each other, have no trusted intermediary, but are willing to found trust on the cost of computation.
That isn't the situation that the financial industry is in - there, it is a lot of existing trust, it is fairly easy to establish trust, there are plenty of trusted intermediaries, and the amounts involved mean that founding trust on computation would be astronomically expensive. A blockchain would be a really bad fit here.
It also sounds like Git and other version control systems with hash chains.
What Bitcoin did different was adding chain selection using accumulated proof-of-work, incentivized using scarce digital tokens within the same database.
