Trace funding readiness from observation to settlement

Before you start.

Set up your workspace

Use owner-scoped funding:read in the agreed environment. Open readiness, bindings, deposits and settlement-intent references below. This exercise issues reads only; it does not prepare a route, activate credit or create a withdrawal.

Examples are illustrative test plans, not customer results. Use only agreed access and non-production material.

Make the first read, then interpret it.

GET /api/v2/funding/readiness

Use a trusted terminal and a scoped, non-production read credential supplied by your approved credential manager. The command sends the authorization header through standard input, not a literal token in the command. Do not enable shell tracing or paste the response into a public report; returned metadata may be private.

# Your approved credential manager must set HC_GUIDE_TOKEN first.
: "${HC_GUIDE_TOKEN:?Set a scoped test credential in this trusted terminal}"
printf 'Authorization: Bearer %s\n' "$HC_GUIDE_TOKEN" | \
  curl --fail-with-body --silent --show-error --header @- \
  'https://api.hybrid-chain.com/api/v2/funding/readiness'

Read the response deliberately

• The optional network_id query selects the network to inspect; use the agreed network, not one inferred from an asset label.
• Retain every unmet gate and distinguish unknown/unavailable evidence from a negative readiness finding.
• Use the separate bindings, deposits and settlement-intent reads to trace lifecycle stages; readiness does not authorize advancing them.

Request paths, authentication modes and named response fields were checked against the published OpenAPI contract. Values are deliberately not filled with a fake live response. Follow the operation links for current schemas and errors.

The workflow at a glance.

Work through one useful case.

A treasury operator sees a deposit and needs to explain why the balance is not yet available for a supplier payment. The task is to follow the records and identify the unresolved stage—not to override it or initiate funds movement.

Keep one working record throughout

Choose one existing test funding route and observed deposit. Build a timeline with route reference, network/chain/currency, readiness observation, deposit confirmation, credit availability and settlement-intent stage. Keep exact amounts as strings and leave missing references blank rather than guessing a relationship.

1. 01

   Pin the route and read its readiness

   Inspect the owner's funding bindings and readiness evidence. Keep network, chain, and currency together in the review. Treat PREPARED as preparation, not activation, and preserve unmet conditions instead of summarizing every returned record as ready.

   Do this

   1. Read readiness for the intended network and inspect the owner's bindings.
   2. Record route posture and unmet gates using the fields actually returned.
   3. Mark PREPARED as prepared, not active, and assign unresolved gates to their owners.

   Expected result

   The timeline begins with the route's actual readiness instead of treating a returned record as activation.

   If your result is different

   If the network or owner is wrong, correct that context before interpreting readiness. Do not combine records from different contexts.

   Result: The operator can name the route, its observed posture, and the conditions still preventing use.

2. 02

   Follow the deposit lifecycle

   Read the observed deposits and inspect the confirmation progress, reserve commitments, and credit-availability state actually returned. Preserve exact decimal amounts and asset identifiers. First-observed valuation is retained context, not a fresh price quote or a promise of spendable value.

   Do this

   1. Open the deposit collection and select one observed test deposit.
   2. Record amount/currency, confirmation progress, reserve evidence and credit-availability state separately.
   3. Retain first-observed valuation as historical context rather than a current quote.

   Expected result

   A reader can explain why an observed deposit may not yet be available for use.

   If your result is different

   An empty collection does not justify sending funds for a tutorial. Obtain a provisioned test record or mark this step unavailable.

   Result: The reconciliation view distinguishes seeing a deposit from making its value available to use.

3. 03

   Inspect the intended settlement separately

   Use the owner's settlement-intent records to review authorization, reservation, signing, broadcast, and finality posture. Link only records whose returned references support the relationship. Never join unrelated deposits and intents solely because their amounts happen to match.

   Do this

   1. Inspect the settlement-intent collection and select a record only when its references support the relationship you are reviewing.
   2. Write authorization, reservation, signing, broadcast and finality in separate timeline columns.
   3. Leave unmatched references unresolved even when two amounts happen to be equal.

   Expected result

   The report shows the specific settlement stage without inventing a link or a completed transfer.

   If your result is different

   If a record disappears or a read fails, preserve the last observation time and re-read current state; do not label cached data as current finality.

   Result: The report shows the actual settlement stage, or explicitly says no matching intent has been established.

4. 04

   Reconcile an incomplete case

   Use an agreed test case with missing confirmation or unmet readiness. Record the observation time and authoritative references, then assign the unresolved condition to its owner. After a lost response, inspect current state before considering any separately authorized mutation or retry.

   Do this

   1. Choose an incomplete case already available in the test evidence.
   2. Write the missing condition, responsible system and next read/check that would resolve it.
   3. Finish with a reconciliation note, not an automatic retry or release instruction.

   Expected result

   The exercise produces a repeatable operator explanation for an incomplete funding or settlement stage.

   If your result is different

   A timeout is not proof that a mutation failed. Any later authorized retry must reconcile the owning service's state first.

   Result: The team has a repeatable exception-handling process without turning uncertainty into duplicate movement.

Test where the workflow stops.

A useful pilot explains failure as clearly as success. Record what you observed rather than presenting these expected checks as completed results.

Binding is PREPARED

Keep receiving-credit and value-movement actions unavailable; preparation is not activation.

Deposit is observed but credit is unavailable

Show the unresolved lifecycle condition instead of treating a displayed amount as spendable.

A settlement request has no finality evidence

Preserve its actual stage. A request or broadcast is not final settlement.

Read fails or the owner context changes

Do not reuse another owner's cached result or label stale evidence as current readiness.

Your acceptance checklist.

Retain the environment, contract version, test time, redacted observations, unresolved dependencies, and responsible reviewer in your private evaluation report.

Keep the contract close.

These links point to documented operations, not executable controls. Check the current request schema, scopes, errors, and implementation status before using them. No credentials or live customer responses are embedded in this guide.

Read the published OpenAPI definition

Choose your next step.

Keep your worksheet and error notes. Continue with the next technical exercise using the same reference trail, and mark any stage that remains untested rather than treating the checklist as a completed deployment.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.