Topics;
-
Systems development and quality assurance
-
Systems operations
-
Execution and Contract Behavior
-
Business continuity-disaster recovery planning and resources;
-
Capacity and performance planning;
-
Exogenus Event Planning
-
IT Security
Fail Safe Mechanism
Smart contracts may not include appropriate or sufficient backup / failover mechanisms in case something goes awry.
-
Smart contracts may depend on other systems to fulfill contract terms. These other systems may have vulnerabilities that could prevent the smart contract from functioning as intended.
-
Some smart contract platforms may be missing critical system safeguards and customer protections.
-
Where smart contracts are linked to a blockchain, forks in the chain could create operational problems.
-
In case of an operational failure, recourse may be limited or non-existent — complete loss of a virtual asset is possible.
-
Poor governance. Smart contracts may require attention, action, and possible revision subject to appropriate governance and liability mechanisms.
-
Low Level Monotiroing of Deployed Contracts (e.g. QuickBlocks)
-
Failsafe mechanism to return to us in case of attack or error
-
Best Practices
-
Auditing by 3rd Party
-
Functional Lanaguage Approach to design (e.g. KVM)
-
FailSafe Switch -
Active Monitoring
Smart Contract Monitoring:
- Actively monitor one (or more) Ethereum smart contracts and user accounts (or any combination) watching for odd or “known-dangerous” transactional patterns. Report to anomalies to a list of email, SMS, web site, or individuals whenever something of interest happens.
| End Users: | Smart contract developers, smart contract participants (i.e. token holders) |
|---|---|
| Notes: | “Weird” things include recursive attacks, violations of invariants (token balances to ether balance), largest purchases, most active trader accounts, etc.; Could potentially spawn an “insured” smart contract industry expectation. |
Smart Contract Reporting:
- Instantaneous “Quarterly” reports available every second. On demand reports generated for cap tables (report on token holders), individual ether holdings and transaction histories (i.e. bank statements) on a per-account, per-contract-group, by industry, or system wide.
| End Users: | Smart contract developers, smart contract participants (i.e. token holders), economists, regulators |
|---|---|
| Notes: | Allows for self-reporting on business processes, expenditures, and revenue from outside an organization—no need to wait for company reports; marketing efforts might engender an expectation that every smart contract’s accounting is fully transparent. |
Auditing Support:
Provide data and transactional information to third parties not associated with the development team of a smart contract system. Interesting to potential investors, industry analysts, auditors and/or regulators.
| End Users: | regulators, auditors, potential investors |
|---|---|
| Note: | Fully parsed data makes for much easier auditing of smart contracts, could expose non-delivery of promised behavior (i.e. are “provably true” gambling sites actually paying out at the rate they claim? Gambler Watch™). |