Four-eyes approvals

The request waits in the approvals inbox. Approving it runs the maker’s stored request, so the approver approves exactly what the maker made; for a one-approver action, the first approval runs it. Tx 1 is the action’s own ledger transaction, submitted by the venue’s party, where the action has one (a forced transfer, for example). Many four-eyes actions are the venue’s own records and have no ledger transaction.

Which actions need how many approvers

Approvers besides the maker	Actions
None: one call, at once	Freeze or limit an investor; pause an asset; run reconciliation; make a reserve’s report; revoke a standing approval
One	Record an asset; open, amend or close a reserve, or propose or release a lock agreement; propose the issuer powers; tighten a policy; record an investor’s attributes, or onboard it with an outside KYC; close an investor or register its successor; execute a distribution; map an outside account; propose a provision settlement
Two	Release a hold; lift a freeze; a forced transfer; a recovery; grant a standing approval; loosen a policy (which then also waits out a day’s notice)

Worked example

Case	What happens
Two approvers, in the inbox	Risk asks to release the hold a reconciliation finding set. Amy signs and the action shows “1 of 2 approvals”; Abe signs and the release runs. Neither of them could be the maker.
Getting round four eyes	A person who holds both the maker and the approver roles cannot approve their own action, and neither can a second sign-in of theirs that carries only the approver role. A decided action is final, and a rejected one cannot be sent again under its key.
A freeze lifted (demo, chapter 9)	The venue’s maker asks for the lift; two approvers sign it.

Controls

An approver must be a different person from the maker. The check is on the sign-in’s identity, so holding two roles never lets anyone approve their own action.
The auditor never approves any action.
Approving runs the maker’s stored request as it was made; an approval of a different request is refused.
A maker may withdraw its own request, or an approver reject it, with a reason; either way it never runs.
Each operation records its maker and its approvers, and the record survives a restart of the engine.

Do it

GET  /v1/approvals                          # what awaits an approver, and what each maker waits on
GET  /v1/approvals/{actionKey}              # one action: its request, maker, state and approvers
POST /v1/approvals/{actionKey}:approve      # runs the stored request, as if the approver had sent it
POST /v1/approvals/{actionKey}:reject       # by an approver, or by the maker withdrawing its own

A four-eyes call answers awaiting with its actionKey, and Location to the approval. See Four eyes. Related: Actors and roles · Holds, freezes and issuer powers

Start here

Workflows

Foundations

Four-eyes approvals

Which actions need how many approvers

Worked example

Controls

Do it

​Which actions need how many approvers

​Worked example

​Controls

​Do it

Which actions need how many approvers

Worked example

Controls

Do it