HYBRID-CHAINDEVELOPERS
DOCUMENTATIONv2
POST

Funding & settlement

Complete settlement consent

/api/v2/funding/settlement-intents/{intent_uuid}/consent
AUTHENTICATIONBearer token · funding:consentAUTHORITATIVE OWNERfunding-serviceCONTRACT AUTHORITYGenerated Rust OpenAPISTATUSSource ready · production listed

PURPOSE + BUSINESS CONTEXT

Advance the exact-intent customer-consent ceremony through challenge, native-plus-passkey preauthorization, and OPAQUE receipt completion without accepting a password or authorizing broadcast.

WHEN THIS CALL IS USEFUL

Use after creating an intent to run the three-phase proof ceremony that binds the customer physically and cryptographically to that one unchanged settlement intent.

OUTCOME · Create or advance

What changes

CHALLENGE issues short-lived material; PREAUTHORIZE verifies native and WebAuthn proofs and returns an OPAQUE broker ticket; COMPLETE retains commitments and wakes later authorization. None signs, broadcasts, or moves value.

WHY IT MATTERS

  • Gives people and agents a contract-backed way to advance complete settlement consent.
  • Connects funding observations to exact owner, instrument, wallet, rail, and settlement context without making the gateway the owner of value.

ISOLATION + AUTHORITY

Owner, workspace, network, instrument, wallet, rail, custody, collateral, compliance, and settlement authorities remain separate. A prepared route, observed deposit, accepted intent, completed consent, reservation, broadcast, or Explorer record does not itself prove final settlement or authorize value movement.

BEFORE YOU CALL

  • Authenticate at the documented boundary: bearer+scope.
  • Supply the required intent_uuid (path), phase (body), network_id (body) exactly as defined by the live contract.
  • Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
  • Resolve the owner, network, instrument or wallet, rail, and settlement context before relying on this result.

WHAT TO DO NEXT

  • Re-read complete settlement consent using the canonical identifier returned by this operation.
  • Reconcile an ambiguous response with the same idempotency key before attempting another mutation.
  • Reconcile the returned state against the authoritative wallet, rail, and settlement record before advancing or retrying.

AGENT GUIDANCE

  • Use complete settlement consent only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
  • Supply the required intent_uuid (path), phase (body), network_id (body) exactly as defined by the live contract.
  • Preserve amounts and fees as exact decimal strings and distinguish observed, accepted, authorized, reserved, broadcast, confirmed, settled, reversed, and reconciled states.
  • After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
MACHINE CONTRACT

The exact deployed parameters, schemas, responses, security requirements, and Hybrid-Chain agent metadata are authoritative at this operation's production OpenAPI JSON Pointer. The readable tables below add integration guidance; the deployed OpenAPI controls if guidance and the machine contract ever differ.

Open the authoritative production contract

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

Examples illustrate integration intent; the referenced OpenAPI operation and component schemas define the executable shape.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE
AuthorizationheaderRequired

Bearer tokenCredential containing the funding:consent scope.EXAMPLEBearer hc_live_…

Idempotency-KeyheaderRequired

ASCII string · 1–128Caller-generated key reused for every retry of the same logical mutation.EXAMPLElaunch-treasury-v1-001

Content-TypeheaderRequired

application/jsonSigned mutations accept canonical JSON only.EXAMPLEapplication/json

Content-DigestheaderRequired

RFC 9530 SHA-256 digestDigest of the exact transmitted body bytes.EXAMPLEsha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:

Signature-InputheaderRequired

RFC 9421 signature parametersCovers @method, @path, content-digest, content-type, and idempotency-key; includes keyid, nonce, created, and expires.EXAMPLEsig1=("@method" "@path" "content-digest" "content-type" "idempotency-key");created=1786582800;expires=1786583100;nonce="01J…";keyid="machine-prod"

SignatureheaderRequired

Ed25519 HTTP Message SignatureSignature made by an active public key registered to the authenticated client.EXAMPLEsig1=:base64-signature:

intent_uuidpathRequired

identifierOwner-scoped intent whose immutable request commitment every proof targets.EXAMPLEintent-01

phasebodyRequired

CHALLENGE | PREAUTHORIZE | COMPLETEExplicit phase; fields for another phase are rejected.EXAMPLEPREAUTHORIZE

network_idbodyRequired

hybrid-devnet | hybrid-testnet | hybrid-mainnetMust match owner, intent, source activation, credentials, and proofs.EXAMPLEhybrid-testnet

challenge_uuidbodyOptional

32-character hexadecimal identifierRequired for PREAUTHORIZE and COMPLETE; must be fresh, open, and issued for this intent.EXAMPLEeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

canonical_intentbodyOptional

canonical key-sorted JSON stringPREAUTHORIZE only; must byte-match the CHALLENGE result.EXAMPLE{"challenge_uuid":"…","intent_uuid":"intent-01"}

signature_hexbodyOptional

128-character hexadecimal Ed25519 signaturePREAUTHORIZE only; native-wallet proof over canonical_intent.EXAMPLEffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

passkey_assertionbodyOptional

WebAuthn assertion objectPREAUTHORIZE only; verifies presence, verification, RP ID, origin, challenge, and credential.EXAMPLE{ credential_id, client_data_json, authenticator_data, signature }

receiptbodyOptional

OPAQUE authorization receipt objectCOMPLETE only; password-broker receipt. Passwords and password files are forbidden.EXAMPLE{ credential_uuid, authorization_uuid, receipt }

REQUEST

JSON body example

{
  "phase": "PREAUTHORIZE",
  "network_id": "hybrid-testnet",
  "challenge_uuid": "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
  "canonical_intent": "{\"challenge_uuid\":\"…\",\"intent_uuid\":\"intent-01\"}",
  "signature_hex": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
  "passkey_assertion": {
    "credential_id": "base64url…",
    "client_data_json": "base64url…",
    "authenticator_data": "base64url…",
    "signature": "base64url…"
  }
}

RESPONSES

Status and payload examples

201Requested consent phase completed; only next-step material or proof commitments are returned.Mutation completed · JSON RESPONSE+
{
  "phase": "PREAUTHORIZE",
  "consent_uuid": "consent-01",
  "native_proof_commitment": "1111111111111111111111111111111111111111111111111111111111111111",
  "passkey_proof_commitment": "2222222222222222222222222222222222222222222222222222222222222222",
  "opaque_ticket": "short-lived-purpose-bound-ticket…",
  "password_transmitted_to_core": false,
  "value_bearing_operations_permitted": false,
  "next_required_action": "COMPLETE_OPAQUE_AUTHORIZATION"
}
INTEGRATION DECISION
CALLER ACTION
Accept the returned representation or receipt, then re-read complete settlement consent using the canonical identifier returned by this operation.
RETRY SAFETY
Do not repeat a successful mutation merely to confirm it. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Persist returned identifiers, versions, commitments, and receipts. Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
200Equivalent completed phase or exact-intent consent returned idempotently.Mutation completed · JSON RESPONSE+
{
  "consent_uuid": "consent-01",
  "customer_consent_verified": true,
  "idempotent": true,
  "funds_moved": false
}
INTEGRATION DECISION
CALLER ACTION
Accept the returned representation or receipt, then re-read complete settlement consent using the canonical identifier returned by this operation.
RETRY SAFETY
Do not repeat a successful mutation merely to confirm it. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Persist returned identifiers, versions, commitments, and receipts. Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
400The phase or its conditional material is malformed.Request must change · JSON RESPONSE+
{
  "code": "invalid_consent_phase",
  "message": "The phase or its conditional material is malformed."
}
INTEGRATION DECISIONinvalid_consent_phase
CALLER ACTION
Rebuild the request from the live OpenAPI operation and correct the rejected method, media type, header, parameter, or body field.
RETRY SAFETY
Do not retry the same invalid request. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Compare the submitted values with the documented constraints before another call. Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
401The bearer credential is invalid.Authentication required · JSON RESPONSE+
{
  "code": "invalid_credentials",
  "message": "The bearer credential is invalid."
}
INTEGRATION DECISIONinvalid_credentials
CALLER ACTION
Discard the rejected credential, complete the documented authentication or reassertion flow, and rebuild any request signature with fresh timestamps and nonces.
RETRY SAFETY
Retry only with a newly valid credential and fresh replay-protection values. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Assume the outcome is unknown only when the connection failed after transmission; otherwise authentication failed before domain work. Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
403Scope, subject, native, passkey, OPAQUE, RP, origin, presence, or verification proof failed.Authority or policy denied · JSON RESPONSE+
{
  "code": "consent_proof_failed",
  "message": "Scope, subject, native, passkey, OPAQUE, RP, origin, presence, or verification proof failed."
}
INTEGRATION DECISIONconsent_proof_failed
CALLER ACTION
Verify the exact scope, tenant or workspace membership, owner boundary, step-up purpose, feature policy, and resource eligibility. Never broaden authority automatically.
RETRY SAFETY
Do not retry until the missing authority or policy condition has been deliberately resolved with least privilege.
STATE RECONCILIATION
Confirm the caller and resource resolve to the same authority boundary for owner-scoped funding methods, deposit instructions, transfer intents, settlement progress, and delivery receipts.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
404The intent, challenge, enrollment, credential, or pinned authority was not found.Resource not visible · JSON RESPONSE+
{
  "code": "consent_resource_not_found",
  "message": "The intent, challenge, enrollment, credential, or pinned authority was not found."
}
INTEGRATION DECISIONconsent_resource_not_found
CALLER ACTION
Verify the canonical identifier and authenticated owner boundary. A 404 may intentionally conceal a resource outside the caller's authority.
RETRY SAFETY
Do not retry the unchanged identifier repeatedly. Refresh the relevant collection or lookup before choosing another identifier.
STATE RECONCILIATION
Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
409Intent state is ineligible, challenge expired or was consumed, proof targets another intent, key epoch changed, or idempotency conflicts.State reconciliation required · JSON RESPONSE+
{
  "code": "consent_conflict",
  "message": "Intent state is ineligible, challenge expired or was consumed, proof targets another intent, key epoch changed, or idempotency conflicts."
}
INTEGRATION DECISIONconsent_conflict
CALLER ACTION
Stop the mutation sequence and fetch the latest authoritative resource, lifecycle state, version, ETag, reservation, or existing idempotency result.
RETRY SAFETY
Retry only after reconciling the conflict. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
422Canonicalization, proof binding, receipt freshness, exact-intent, or network policy failed.Request must change · JSON RESPONSE+
{
  "code": "consent_binding_rejected",
  "message": "Canonicalization, proof binding, receipt freshness, exact-intent, or network policy failed."
}
INTEGRATION DECISIONconsent_binding_rejected
CALLER ACTION
Rebuild the request from the live OpenAPI operation and correct the rejected method, media type, header, parameter, or body field.
RETRY SAFETY
Do not retry the same invalid request. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions.
STATE RECONCILIATION
Compare the submitted values with the documented constraints before another call. Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.
503Funding consent, WebAuthn, OPAQUE, Identity, or evidence retention is unavailable; consent is not inferred.Dependency unavailable or outcome uncertain · JSON RESPONSE+
{
  "code": "consent_unavailable",
  "message": "Funding consent, WebAuthn, OPAQUE, Identity, or evidence retention is unavailable; consent is not inferred."
}
INTEGRATION DECISIONconsent_unavailable
CALLER ACTION
Preserve the exact request and treat the outcome as uncertain until authoritative state proves whether it committed.
RETRY SAFETY
Reconcile before retrying. For one logical mutation, retain the same Idempotency-Key and byte-equivalent request. Never reuse that key for changed instructions. Use bounded backoff with jitter.
STATE RECONCILIATION
Refresh the funding method and transfer or deposit lifecycle; compare amount, asset, network, destination, provider reference, and terminal settlement evidence.
ESCALATE WHEN
Escalate when money movement is ambiguous, provider and ledger states disagree, or a destination or asset cannot be proven exact.

OPERATIONAL NOTES

Security and lifecycle guarantees

  • This reviewed planning contract is non-executable until present in production OpenAPI.
  • Call CHALLENGE, PREAUTHORIZE, and COMPLETE in order. Any intent, request commitment, wallet-key epoch, participant set, policy, credential, network, challenge, or expiry drift requires a new challenge.
  • Never send a password, password file, private native key, passkey private key, biometric data, seed, MPC share, signing nonce, or reusable authentication secret.
  • Completed consent means the customer approved this exact intent. It is not custody authorization, collateral availability, MPC completion, broadcast permission, validator finality, settlement completion, or production-value enablement.
DOCUMENTATION STATUS

This route is implemented in canonical gateway source and appears in the production OpenAPI snapshot observed 2026-09-11T06:35:11.572Z. Authentication, tenant, feature, venue, and market policy still apply.

Verify the exact production OpenAPI operation Return to the V2 directory