30 Blockchain Institutional Readiness Activities

Random Observation/Comment #681: DeFi — so hot right now.

Why this list?

Never a dull moment in the public mainnet and Enterprise Ethereum space. As broad stroke trends, I’ve noticed:

• CBDC experimentation and Central Bank commitments for go-live (not to mention the Digital Yuan already being tested)
• Stablecoins maintaining value for ecosystems to remove the need for fiat off-ramps
• Payment companies looking at Blockchain technology to leverage their existing identity networks
• Traditional Financial Digital Assets (e.g. private equity and bonds) experimentation on mainnet
• DeFi growing to $11B with an incredible Q3 report

If I were an innovation lead in a bank’s IT team, I would consider looking at projects that provide institutional readiness and connectivity to these external market forces. At a high level, I think it’s important to explore:

• Community
• Wallet Experimentation
• Policies
• Thought Leadership
• Platform Integration

A traditional institution follows similar patterns for large buzzword trending technology strategy. I saw this with big data and it has established itself with blockchain/digital assets. Starting from the bottom left, your strategist considers bringing the highest value with the fewest resources and eventually leads to creation of products that are handed off to the proper product line. To get you started and bootstrap your Blockchain Working Group, consider:

1. Join standards organizations for guidance — Hyperledger Foundation and Enterprise Ethereum Alliance (EEA) are good starts to getting an idea of what projects have already gained traction. You need to know what use case you’re solving for and get inspiration from presentations.
2. Ask your trusted vendor/advisor — More often than not, your standard vendor (e.g. McKinsey, Deloitte, etc) will have a blockchain strategy and recommendation based on your provided use case. At ConsenSys, we reach out to advisory partners to recommend Ethereum in the right use cases. You can always reach out to us directly.
3. Internal Testnet — You will likely need to do this for multiple ledger types. All developers start off with local testing via Truffle/Ganache or directly with ‘npx quorum-dev-quickstart’. Later on, you may want to look at Kaleido as a full Blockchain-as-a-Service devops tool or directly create servers from Azure/AWS accounts. Creating a 3-node testnet is great for devops learnings and running experiments on standard use cases.
4. Enterprise Developer Community — Internally create a Confluence/Sharepoint page with an internal sign-up to stay updated on ecosystem announcements. Creating interest from internal groups will draw younger developers and possible cycles for experimental projects.
5. Showcase Applications — There are more than enough public projects that are open source and can be deployed in your testnet. I personally love following Austin Griffith and his eth.build and scaffold-eth for quick starts. Also, most Ethereum smart contracts are open source, so you can literally go into Etherscan Smart Contracts directory and find interesting design patterns.
6. Hackathons — Hosting your own internal hackathon (hopefully supported by your internal architecture community of practice/WG) will help build that initial subscription list of developers and maybe provide a platform for sponsors to award a side project for future funding. A weekend of hacking can lead to a collaboration of ideas and connections from within the company.
7. Educational Material — On a monthly or quarterly basis, send updates of educational material. You can subscribe to some newsletters to share a combination of relevant articles or provide links to online resources. Definitely keep documentation on all POCs that you’ve explored and lessons learned from multiple iterations.
8. Training Courses — Consider an online training course for your team if it’s early days. It was more effective for in-person training, but it could also be rewarding to get online certifications for passing courses on Ethereum development. Try out ConsenSys Academy.
9. Write an Evaluation Framework for Use Cases — This mainly depends on how your organization approves business cases. Is it an investment into the technology? Is it a certain rubric that can output the impact to existing systems that cover the same functions? Is there a total cost of ownership analysis? Are use cases that touch fewer core features like post-trade much easier to pass?
10. Create a presentation of relevant Use Cases — You can probably ask your trusted advisor to provide a methodology for approaching this and get a list of high value case studies from published papers. I personally love the Ubin Phase V report which describes how a payments network can improve post-trade processing and provide efficiencies to existing banking systems.
11. Evaluation Framework for Technology Platforms — There’s a lot of choices for enterprise platforms, but I still think Ethereum, Hyperledger Fabric (IBM), and Corda (R3) are the top that have the largest collaborations and momentum. Out of these, Ethereum is the only one that depends less on a single organization for licenses and has a standing public network with real transaction market value. That being said, there are advantages and tradeoffs made by all these designs.
12. Institutional Custody Experimentation — Based on the recent OCC ruling with cryptocurrencies and stablecoins, I think it makes sense to think about what an institutional custody solution might look like connecting your retail bank to a cryptocurrency exchange or limited alternative asset fund. Perhaps this s much more realistic for private banking partners and high net worth clients.
13. Institutional Custody recommendations — If the bank itself cannot provide the key management and custody arrangements necessary to pass security checks, it may make sense to have partners that fulfill these gaps.
14. Institutional Wallet — Large institutions may want to play a role in being custodians for smaller players. This might be an internal use case of providing a network for a number of existing partners.
15. Retail-facing Wallet — If a retail CBDC digital dollar is created, then how would a consumer’s bank account look? Does it have another account type just for CBDC balance? Is it a mobile add-on to your existing account? Is there a physical key storage mechanism on the phone?
16. Joining Consortiums — It’s always easier to join a consortium than do the hard work of creating a new one. Based on the connections you’ve met at conferences or through the ecosystem, it makes sense to know how to evaluate which consortium to join and leverage the upside with your limited resources.
17. Governance Policies — One of the most important parts of permissioned blockchain networks is the necessary relationship with legal teams reviewing the stipulations of joining a membership or product that requests you host your own node. The legal hardship has caused the most delays across the board.
18. Security Audits — If you’re mature in your blockchain development life cycle, you will eventually want to tie in your security audit team to make sure your applications can go-live. If you wrote your own smart contracts, consider hiring our ConsenSys Diligence team to review them.
19. Deployment Policies — Dapps are slightly different from traditional web apps. There will be a lot of off-chain Ethereum address key management and mapping to identities. You may also want to configure your testnet to limit the types of TXs possible.
20. Architecture Alignment — Most organizations have long term architectural decisions around languages and approved technology. Depending on your organization, you may need exceptions for solidity or any tech that might be non-standard to a traditional on-prem bank.
21. Cloud connectivity — While on-prem is possible with enterprise installations, it becomes prohibitively annoying to go-live when dealing with client and software upgrades with long term support. The standard process of repackaging software from vendors on a weekly basis is too slow for patching fixes. For cloud providers, you can get delegated accounts that can provide support teams with access to push updates.
22. Market Analysis (Trends) — It’s important to attend online conferences and webinars to stay on top of the latest fintech and blockchain trends. ConsenSys publishes a number of webinars.
23. Participation Opportunities — Consider the role your institution plays within a digital asset ecosystem. Perhaps you can be an underwriter, an agent, or a custodian. Projects are often looking for multiple ecosystem participants in order to fulfill an end-to-end digital asset transaction.
24. Investment Opportunities — Startups have been fundraising to support their blockchain ideas. Consider meeting these companies for possible investment ideas and learn more about the different fintech use cases being explored.
25. Internal Use Cases — Off of the hackathons, consider building your own testing sandbox for your team. I’ve seen testnets integrate to bank ID APIs. A base dashboard of dapps published on your testnet could help foster a more interactive community.
26. Understand your company’s Business Capability Model and how Blockchain can impact it — Early iterations of blockchain mapping often looked at where data storage can benefit from being shared with peers. I think the data storage use cases are still relevant, but an updated mapping might be considered based on financial patterns learned from defi.
27. Liquidity and Collateral Management — If you assume digital assets and payments will be disrupted in the next phase, your bank will need to figure out how to manage their current and future representations of tokens. This could just be another line item in your accounting system of a “type” or to the consumer-side another type of bank account “CBDC” instead of checking/savings. Once you have this bearer instrument, you’ll need to optimize how it gets circulated and spent. What’s super interesting to me is the token allocations as bearer instruments does not allow for the bank to create fake credit accounts like Savings accounts. Banks cannot control how that money is moved around, withdrawn or spent in the backend because the consumer would have direct wallet access to send/process TXs.
28. Data and Identity Management — If this is related to FX, you’ll need to connect your token ownership to new identities and connect them to market pricing execution (depending on the use case).
29. System Integration Impact — Alongside data and identity management, it’d be good to take note of what applications will likely need to be updated if a CBDC API or framework is provided to your bank. Which systems will need to subscribe to a stream of events and push data out of the bank? What does the wall look like?
30. Write an RFP/RFI — This has been the most effective way for an institution to solidify requirements and signal to vendors and the business side that there is budget available to execute the vision of this proposal. It’s a standard gating factor for protecting the overall strategy and validating which technology provides the least lift for return on investment. As a vendor, we hate answering RFPs (because it’s a lot of upfront sunken cost), but we know winning this usually lands a few million dollars in pricing/delivery.

ConsenSys provides services that covers most of these aspects. We can help you setup your environment and connect to the vibrant Ethereum community while completing lightweight POCs for you to ask for more budget. We know how to go-live if you get there and can share

~See Lemons Build Institutional Readiness

Originally published at https://seelemons.com on October 20, 2020.