Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.keystoneos.xyz/llms.txt

Use this file to discover all available pages before exploring further.

The SettlementCoordinator is the core on-chain contract. It stores settlement state machine rules, enforces valid transitions, and operates autonomously after compliance - auto-dispatching releases when all deposits are confirmed.

Functions

createSettlement()

Registers a new settlement on-chain with its state machine rules, legs with commitment hashes, and timeout. Uses the commitment scheme - no party addresses are stored at registration time.
struct LegSpec {
    address token;
    uint256 amount;
    bytes32 depositKey;      // keccak256(depositSecret)
    uint8   tokenStandard;   // 0=ERC-20, 1=ERC-721, 2=ERC-1400, 3=ERC-3643
    FeeSpec[] fees;          // Fee recipients and amounts
}

struct FeeSpec {
    address recipient;
    uint256 amount;
}

function createSettlement(CreateParams params) external
ParameterDescription
settlementIdUUID converted to bytes32 (16 bytes UUID + 16 bytes zero padding)
initialStateIndex of the initial state in the template’s states list
transitionsArray of allowed (fromState, allowedTargets[]) rules
gatesArray of (state, gateType) pairs defining preconditions
partyHashesKeccak256 hashes of party identifiers
legsArray of LegSpec structs with deposit keys and fee specs
timeoutAtUnix timestamp deadline for the settlement
autonomousWhether the coordinator auto-executes after all deposits
terminalStatesArray of terminal state indices
Commitment scheme: Each leg’s depositKey is the keccak256 hash of a random secret. The party who knows the secret can deposit on that leg. No addresses are registered - this preserves pre-execution privacy on public chains. Emits: SettlementCreated(bytes32 settlementId)

transition()

Proposes a state transition. The contract validates the proposal against the registered rules and gate checks before accepting. Used by the KeyStone engine for compliance-phase transitions only.
function transition(
    bytes32 settlementId,
    uint8 targetState,
    bytes32 evidenceHash
) external
ParameterDescription
settlementIdThe settlement to transition
targetStateIndex of the target state
evidenceHashSHA-256 of "fromState:toState:triggeredBy" for audit
The contract performs the following checks:
  1. Settlement exists and is not in a terminal state
  2. (currentState, targetState) is in the registered transitions list
  3. If the target state has a gate, the gate condition is met
  4. Caller is authorized (coordinator role)
Emits: StateTransition(bytes32 settlementId, uint8 fromState, uint8 toState, bytes32 evidenceHash)

notifyDepositsComplete()

Called externally by the API (event indexer) when an AllDepositsComplete event is detected from the escrow contract, or received via LayerZero (cross-chain) when all legs for a settlement have been deposited. This triggers the coordinator to auto-advance the settlement. The coordinator:
  1. Verifies allLegsDeposited == true via the escrow contract
  2. Transitions from AWAITING_DEPOSITS to EXECUTING_SWAP
  3. Dispatches release instructions to all escrow contracts (via LayerZero for cross-chain)
  4. Settlement auto-finalizes
This is the key to autonomous post-compliance execution. No KeyStone involvement is needed.

_lzReceive()

Receives cross-chain lock confirmations from escrow contracts via LayerZero. When all chains have confirmed their deposits, the coordinator auto-advances to execution and calls executeSettlement with recipient addresses to trigger releases.

timeout()

Triggers a timeout for an expired settlement. This call is permissionless - anyone can call it after the deadline. No dependency on KeyStone.
function timeout(bytes32 settlementId) external
The contract checks:
  1. Settlement exists and is not in a terminal state
  2. block.timestamp >= timeoutAt
When triggered, the coordinator dispatches rollback instructions to all escrow contracts (via LayerZero for cross-chain), returning deposits to their original owners. Emits: SettlementTimedOut(bytes32 settlementId, uint8 fromState)

View functions

function getSettlement(bytes32 settlementId) external view returns (Settlement)
function getState(bytes32 settlementId) external view returns (uint8)

Events

EventWhenPurpose
SettlementCreated(bytes32 settlementId)New settlement registeredAudit trail, indexer trigger
StateTransition(bytes32 settlementId, uint8 fromState, uint8 toState, bytes32 evidenceHash)Any state changeImmutable transition record
SettlementTimedOut(bytes32 settlementId, uint8 fromState)Timeout triggeredAudit trail, triggers rollback
These events form the complete settlement audit trail. Any third party can independently reconstruct the full settlement history by reading events from the chain.

Gate types

Gates are preconditions checked before a transition is accepted:
Gate TypeContract CheckedFunction Called
COMPLIANCE_CLEAREDComplianceRegistryareAllPartiesCleared(settlementId)
ALL_DEPOSITS_CONFIRMEDKeystoneEscrowallLegsDeposited(settlementId)
Gates are configured per-state at settlement creation time.

Access control

FunctionWho Can Call
createSettlement()Anyone (permissionless)
transition()Coordinator role only (KeyStone engine)
notifyDepositsComplete()Coordinator role (called by API after AllDepositsComplete event)
_lzReceive()LayerZero endpoint only
timeout()Anyone (permissionless, after deadline)
getSettlement() / getState()Anyone (view)
The coordinator role is the only privileged role. It allows the settlement engine to propose transitions during the compliance phase. Post-compliance, the contracts operate autonomously without the coordinator role.

Data conversion

SourceTargetMethod
UUID (16 bytes)bytes32Right-pad with 16 zero bytes
State name (string)uint8Index in template’s states list
Evidencebytes32SHA-256 of "from_state:to_state:triggered_by"
Party identitybytes32keccak256(abi.encode(participantId_bytes32, walletAddress))