Policy Contract

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

A policy contract specifies the policies that a token must satisfy, e.g., whether a token must be spent on the product or services supplied by eligible sellers or how many tokens can be spent in a transaction.

Context

A payment should be settled only when specific business rules or policies are satisfied. For example, government support programs or charitable donations usually indicate limits and constraints regarding products/services that could be purchased, their quantities, and eligible sellers.

Problem

How to specify policies governing the use of one or more tokens and validate them by the payment applications before allowing a payment?

Forces

  • Diversity – A variety of policies often govern the use of a token. They are challenging to find and interpret in relation to one another.
  • Dynamism – The policies or business rules are dynamically attached/removed to/from tokens.
  • Complexity – The policies or business rules are complex and difficult to codify.

Solution

A policy smart contract can be designed to specify policies that a token must satisfy before use. The following figure shows the sequence of activities to specify and use a policy contract. First, the issuer creates a policy smart contract and deploys it to the blockchain. For example, the contract could specify that an attached token is spendable only on medicine, and the corresponding policy check logic could validate whether a given pharmacy is registered in the approved seller registry (i.e., a registry smart contract that maintains the information of eligible sellers from whom the token can be spent to purchase that medicine). Then the token contract can link the deployed policy to any newly issued token. When the buyer requests the token transfer during payment, the token contract (or token registry, not shown in the figure) can validate the policy by calling the policy contract. When all the policy conditions are satisfied, the token balance is updated on the token contract (or token registry). If the payment conditions are unsatisfied, the transaction is rejected.

Sequence diagram of policy contract

Sequence diagram of policy contract

The policy check logic could be implemented as smart contract methods that are invoked before the payment function. It is also possible to specify a generic method to validate a policy document given in a pre-specified format. For example, JSON schema could be used to specify policies that can be codified as key-value pairs. The mapping of policy contracts can happen at the level of either a single or group of tokens. In some instances, policies are expected to remain the same until the token is redeemed (or at least within a given time window). In other cases, the policies governing the tokens may change with time (e.g., changes in service agreements). Thus, the issuers may want to enforce the latest policy at the time of spending. Typically, a policy contract needs to be designed with a generic interface such that it can be dynamically attached/detached to/from the token. The attachment can be specified as a tuple consisting of the address of the policy smart contract and a list of policy functions.

Benefits

  • Dynamism – Policy contracts can be flexibly attached, updated, or removed from a token.
  • Diversity – Policy contracts enable issuers to specify a variety of policies in policy contracts for the usage of different tokens.
  • User Productivity – Multiple policies and tokens could be automatically checked using smart contracts without needing the buyer and seller to interpret them manually.

Drawbacks

  • Cost – If a public blockchain is used, an extra cost is required to deploy a policy contract on blockchain and call its functions at the time of transacting.
  • Developer Productivity – Policies are challenging to codify; hence, it takes time to carefully design, develop, and test a policy contract. However, this is a one time process.

Related patterns

  • The token template and token registry patterns can use the policy contract to link and validate the policies that a token needs to satisfy.
  • A policy contract can also be referred when a third party conducts a transaction using the authorised spender pattern.

Known uses

  • Making Money Smart is a joint pilot project by the Commonwealth Bank of Australia and CSIRO’s Data61 that attaches policy contracts to each pouch of tokens issued to redeem National Disability Insurance Scheme (NDIS) benefits in Australia. The policy defines what healthcare services could be used, their quantities, and eligible sellers.
  • Smart Money is a blockchain-based payment platform jointly developed by Kela (The Social Insurance Institution of Finland) and TietoEVRY in cooperation with the Finnish Tax Administration, Financial Supervisory Authority of Finland, and Borenius Attorneys. Spending rules are defined as constraints for smart money tokens and are verified at the time of a transaction.
  • ERC-1400 is a library of standards for security tokens on Ethereum that specify transfer restrictions, rights, and obligations. Polymesh specify how those restrictions can be specified using JSON schema in a KYC (Know Your Customer) setting.
  • CAIPY is a blockchain-based car insurance policy framework. In the design of CAIPY, policy contracts model process fragments defined by the physical insurance policies between customers and insurers. The policy contracts inCAIPYonly govern the conditions for claims, not the use of tokens as insurance payments.