Documentation
¶
Overview ¶
Command foureyes demonstrates SEGREGATION OF DUTIES (the "four-eyes" / maker- checker rule) as a property of the token. A treasury agent may PREPARE a transfer under one human's authority, but EXECUTING it is structurally unreachable unless the token's provenance names a SECOND, DISTINCT human — so an agent (or a single insider) can never both raise and release the same payment.
Three things stack, all enforced OFFLINE at the treasury resource server:
- Tools — the prepare token carries Tools=[prepare_transfer]; it literally cannot call execute_transfer (a signed-token constraint, not a UI gate).
- MaxAmount — prepare and execute are both capped; the cap binds even a fully co-signed transfer.
- Two-distinct-principals — execute_transfer requires ≥2 distinct human principals in the RFC 8693 sub/act chain; one human (even repeated) is refused, so you cannot approve your own request.
No database, no Docker:
go run ./examples/foureyes # or make demo-foureyes
NOTE (honest): Legant's sub/act is a LINEAR delegation chain, not an independent co-signature scheme. This encodes maker-checker as "the execute authority's provenance must contain two distinct humans," enforced offline by the RS over the signed chain. For true independent dual-control over one transfer object, pair this with an approval record the second human signs — Legant carries and verifies the principals; the application defines the workflow.
Source Files