Skip to content


  • 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™).

Last update: June 28, 2020