Loading module
Resolving locale, route permissions, and workspace projection.
Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 60_technical_specs | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 60 days
Approval authority: GOVERNANCE_ADMIN, COMPLIANCE_OFFICER
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
Define a deterministic, rail-agnostic settlement abstraction for governance records while preserving canonical dual record types:
SETTLEMENT_INTENTSETTLEMENT_EVENTThis specification covers governance-layer representation and validation only. It does not define actual payment execution behavior.
railType: one of BLOCKCHAIN, BANK, VASP, INTERNAL_LEDGER.custodyType: one of PLATFORM, PARTNER_ESCROW, SELF_CUSTODY.subjectId: composite identifier <SubjectType>:<SubjectId>.correlationId: deterministic reference linking governance event to external execution attempt.SETTLEMENT_INTENT for obligation creation (SETTLEMENT.CREATE).SETTLEMENT_EVENT with actions SETTLEMENT.<EVENT_TYPE>.string -> string allowlist constraints.ESCROW_OPENED: escrow channel is considered opened by external operator.DEPOSIT_CONFIRMED: deposit is externally confirmed.RELEASE_REQUESTED: release intent has been requested.RELEASE_EXECUTED: release confirmed externally.REFUND_EXECUTED: refund confirmed externally.These semantics are invariant across rails; only external evidence format differs.
All values below MUST be stored using existing allowed keys.
For SETTLEMENT_INTENT:
requestId MUST carry unique deterministic request reference.externalReference SHOULD encode rail and custody context, for example rail=BLOCKCHAIN;custody=PARTNER_ESCROW.memo MAY contain human-readable short context.For SETTLEMENT_EVENT:
externalTxId SHOULD carry rail transaction id where available.providerReference SHOULD carry provider operation id.note MAY carry deterministic normalized status details.authDecisionEntryHash and authDecisionPayloadHash SHOULD be present for traceability.BLOCKCHAIN: externalTxId SHOULD be tx hash; providerReference SHOULD be chain+network reference.BANK: externalTxId SHOULD be bank transfer id; providerReference SHOULD be bank operation code.VASP: externalTxId SHOULD be settlement transfer id; providerReference SHOULD be custody-provider request id.INTERNAL_LEDGER: externalTxId SHOULD be internal posting id; providerReference SHOULD be system journal reference.Adapters SHOULD receive:
policyHashsubjectIdrequestId, providerReference, or deterministic equivalent)Adapters MAY return:
externalTxIdproviderReferenceThese outputs, if persisted to governance, MUST be written through explicit settlement events using allowlisted metadata keys.
verifySettlementAuthorization.verifySettlementEventAuthorization.verifySettlementLifecycle.packages/core/settlement/*.externalReference is a compatibility mechanism to remain within current metadata allowlist.BLOCKCHAIN): intent + escrow-opened event contains deterministic tx hash in externalTxId and passes lifecycle checks.BANK): deposit-confirmed event with bank transfer id in externalTxId and provider op id in providerReference remains valid.VASP): release-requested then release-executed with stable provider references passes ordering checks.INTERNAL_LEDGER): refund-executed followed by release-requested MUST fail lifecycle validation.