Skip to content

Latest commit

 

History

History
95 lines (79 loc) · 3.56 KB

operational-safeguards.md

File metadata and controls

95 lines (79 loc) · 3.56 KB

Operational Safeguards and Systems Continuity We aim for 99.99999% Uptime 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 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. 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. 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™). 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. 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. 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.

(1) Information security;

(2) Business continuity-disaster recovery planning and resources;

(3) Capacity and performance planning;

(4) Systems operations;

(5) Systems development and quality assurance; and

(6) Physical security and environmental controls. b. An explanation of how Applicant will establish and

Rulebook & Member Agreement

Rule Filings

Notices

Jurisdictions

Disclosure Framework