Security: Limit the damage that can be done in the event of a breach.
Security lessons from Web3
Writing smart contracts (blockchain applications) taught me to keep security concerns as a top priority. And after studying a variety of security breaches, it became evident that it’s impossible to ensure 100% that your program has 0 vulnerabilities. Even expensive security audits can’t promise that!
That being said, you can design your system in such a way that likely limits the damage that can be done by a security breach. For example, limiting the amount of funds that can be stolen by limiting the amount of funds stored in one place.
That’s exactly what I did when architecting Web3’s first commercialized solution for on-chain recurring payments. Here’s how the system worked:
Every client (business) gets their own recurring-payments contract — that way a security breach in one won’t necessarily compromise everyone. This also keeps the logic simpler, reducing the chance of shipping a security-compromising bug.
Clients submit transactions to be processed (e.g. set up a recurring payment for a customer, set up payroll for an employee) by the vendor (us) via a normal Web2 API. These transactions are signed and then validated on-chain, so neither the vendor nor a malicious actor can tamper with them.
The transaction specifies whether the transaction is ‘inbound’ or ‘outbound’ from the client’s perspective.
Inbound transactions send funds to a specific wallet address owned by the client, and outbound transactions pull funds from a wallet owned by the client.
Why separate wallets for inbound and outbound transactions?
By using separate wallets, we can contain potential harm incurred by a security breach to a known and acceptable limit. For example, if a malicious attack figured out how to conduct a replay-attack, executing a single transaction multiple times, here’s what would happen:
Inbound Transaction
For an inbound transaction, the replay-attack could potentially drain a customer’s funds, but those funds would end up in the client’s wallet. And thus, the client could easily return the funds.
Outbound Transaction
For an outbound transaction, the attack could drain the funds in the client’s outbound wallet, ostensibly. And in anticipation of this possibility, the client could limit the funds held in this wallet at any given point of time. While no one likes losing $10K, and I put a lot of effort into making sure that doesn’t happen, losing that amount probably won’t destroy your business.