How Boeing, Toyota, Caterpillar, and other OEMs can double their current net profit by using smart contracts to become unmanned “virtual companies”, with or without cryptocurrency: Part 9
A discussion about interoperability and why it doesn’t really matter if Ethereum never stabilizes
First, it’s worth noting that Ethereum is interoperable with many other smart contract platforms. If a different cryptocurrency stabilizes enough for enterprise use before Ethereum does, then the Ethereum smart contracts can simply be migrated over to that other cryptocurrency.
Qtum (https://aws.amazon.com/marketplace/pp/B07FB214D3) and Ethereum smart contracts are forwards-backwards compatible thanks to Qtum’s account abstraction layer.
Cardano is compatible with Ethereum thanks to its KEVM testnet. To quote Charles Hoskinson:
“With Cardano, first off, we’re backward-compatible, 100%, we’re running an EVM. So you can take your Solidity code and your Web 3 stuff and all the things you’ve come to know and love about Ethereum, and you can run it on my system, and it’s faster, cheaper and safer to run it on my system because we have a better consensus model”
Ethereum is also interoperable with fiat money thanks to Chain Link and open banking APIs. Note that I’m not talking about scenario 4 from part 8. I’m talking about a variant of scenario 2 from part 8 where ether isn’t even involved (beyond the cost to run the smart contract on the Ethereum network).
Chain Link integrates with existing bank infrastructure and systems to allow on-chain events (Ethereum) to trigger off-chain payments (bank account sending a payment). How is this possible? We already discussed open banking APIs and PSD2 in part 8. In part 5, we talked about how Chain Link enables off-chain inputs. Let’s talk about how Chain Link enables off-chain outputs via external adapters.
Imagine that the OEM’s smart contract (hosted on the Ethereum network) receives the AI sales forecast via decentralized Chain Link nodes (as described in part 5) and needs to send USD out to the tier 1 suppliers. Chain Link, via a technology called external adapters, can actually use that to trigger an outgoing payment.
A more technical discussion of external adapters can be found here:
- https://medium.com/chainlink/chainlink-external-adapters-e9f99cd6cb62
- https://www.youtube.com/watch?v=_FOB2dL4EQQ&feature=youtu.be
Basically, Chain Link provides the data for the bank account API to make the payment. It doesn’t directly make the payment itself. To directly quote Thomas Hodges on Reddit:
“Essentially, a payments API would use the on-chain result of a smart contract’s event as the trigger to complete payment off-chain with fiat currency”
With the open banking API trends discussed above, banks are now forced to share their accounts data with anyone (that the account holder approves). They cannot monopolize that data anymore. So long as the OEM’s CFO expresses his or her approval for automated outgoing Chain Link payments by logging in to the bank account and registering the on-chain addresses, then that bank account can behave in a conditional and programmable way not unlike on-chain ether.
Once the tier 1 supplier’s bank account receives the funds, then we’re back to Chain Link as an input for any web API (as described in part 5). The state of the tier 1 supplier’s bank account is fed to its own smart contract, which in turn triggers a Chain Link output that automatically send funds to the tier 2 supplier’s bank account (assuming the CTO of the tier 1 has also logged in to the bank account and registered the on-chain addresses). So on and forth (I will describe this cascading domino effect in more detail in part 12).
If desired, all bank accounts return a post-payment digital confirmation receipt for Chain Link to deliver back to the (on-chain) smart contract for the sake of financial auditing and immutable record-keeping. Alternatively, transaction records could be kept off-chain (in the bank accounts only) if a more private and closed-book approach is preferred.
Capable of leveraging trends in both open banking APIs and cryptocurrencies, Chain Link is truly currency-agnostic. It is for this reason that SWIFT is interested in partnering with Chain Link for developing a “SWIFT oracle service”. Formal announcements have been few and far between, but it is speculated that the Chain Link-enabled SWIFT oracle service will be implemented in 2020.
It is for this reason that Chain Link, despite nominally being a cryptocurrency, still comes up in more traditional fintech conversations: https://medium.com/iveyfintechclub/open-banking-apis-creating-real-options-in-making-investment-decisions-330d2c9552cf.
It truly is an “any input, any output” enabler:
All in all, it doesn’t really matter if Ethereum never stabilizes. If a compatible crypto happens to stabilize, then the Ethereum smart contracts can just migrate without breaking a sweat.
If no stablecoin (with smart contract compatibility) ever emerges, then Chain Link’s external adapters and PSD2’s open banking APIs will enable smart contracts in fiat. The smart contract itself will still run on an unstable cryptocurrency’s network (which it has to for the sake of security and immutability, see the discussion about Codius in part 8), but the actual transactions are in normal fiat currency.
How does this work? A rough analogy would be the IBM World Wire. Settlements are handled with the Stellar protocol (which requires small Stellar fees to run), but the actual token of cross-border transfer is a USD-pegged stablecoin that isn’t necessarily Stellar.
Another helpful metaphor for understanding how this works is the multi-colored wires of a servo motor encoder.
Red and black go to power and ground. In other words, they’re the actual muscle. This represents the bank accounts.
The other colors control angular position, RPM, polarity, torque, etc. In other words, the signal inputs that determine how the outputs will trigger. The brains of the motor. Those represent the smart contract.
Motor encoders usually bundle the wires together for the sake of convenience, but they don’t have to be that way. The motor would still work just fine if the power wires went to one circuit board and the signal wires went to another circuit board.
Running a smart contract on the Ethereum network still requires small “gas” fees paid in ether. But this is a minuscule expense compared to the amounts of money that will actually be moved by the outputs of the smart contract.
Just like how the actual kilowatt-hours drawn by the signal wires is a minuscule percentage compared to the kilowatt-hours drawn by the power wires.
In other words, it doesn’t matter if the circuit board for the signal wires is plugged into an outlet with unstable utilities prices. The servo motor (75%-unmanned “virtual company”) can still run smoothly since that instability is such a minor expense compared to the bulk transactions (the power wires going to a different circuit board that plugs into an outlet with stable utilities prices).
In a sense, this is truer to how Ethereum was meant to be used. Ethereum didn’t start out seeking to be the world’s number 2 cryptocurrency. Ethereum’s original claim to fame was being the first “world computer” (Golem and Matrix AI Network are also notable as being world computers). Ether was mostly meant to be fuel for the world computer. Currency was only its secondary function. It was always really about the smart contracts.
Continue to part 10….