How to introduce flexibility in a partially automatic contract

Smart contracts eliminate the ambiguity of the terms and the possibility of a breach, forcing parties to honour their agreements. On one hand parties do not need to monitor each other; on the other hand, flexibility is reduced. This guide aims to suggest how to introduce flexibility within an agreement where one or more of the performances are automated by a smart contract.

1) Attempts to recover an overdue payment/rate/instalment

In order to create a certain level of flexibility in a long-term business relationship, we can insert the provision that in the event of non-payment of an instalment/rate, the contract, instead of ending immediately, provides for the possibility of asking for the amount that has expired and not paid a specified number of times. If despite the payment requests, the debtor does not pay, then the contract ends.

2) Flexibility can be also reached by exploiting tokens.

A system of Tokens can be used as specific rewards and/or penalties for achieving, or failing to achieve, performance levels that affect the bottom line.

Tokens and penalty clause: most of the time compliant parties do not intend, in case of breach of the contract, to request immediately the penalty to the defaulting party. Parties could provide together with the penalty, a number of tokens that act as a warning and incentive to remedy the violation of the clause. Therefore, in case of violation, the party will gradually remove a number of tokens from the defaulting party and will continue to remove them until the violation is remedied. In case of non-compliance and persistent non-fulfilment, the smart contract will be activated with the request for a penalty.

3) Setting tolerance or different fee/price according to the quality of the services received by the customers.

In one of our smart legal contracts, we set up the following smart clause:

“In case of expected service level, Customer shall pay, as indicated above, to the Company, a subscription fee of ( subscription fee amount for expected level) Ether for the Service, which corresponds to Wei . The performance level of the service is measured by the interface address API json call to verify the performance. The expected level is set up on the number/percentage of the expected level value.

If instead, the quality of the service exceeds goals, as above defined, then the Customer shall pay to the Company a subscription fee of (subscription fee for greater service) Ether, which corresponds to Wei ; if the quality of service fails to meet the expected service level described in 8.2, then the Customer shall pay to the Company a subscription fee of (subscription fee for under expected level) Ether, which corresponds to Wei.