Deployment & operations

The operating example

This example represents contractual rights associated with delivery robot ROBOT-A-001 using FlexibleToken, with a cap of 1,000 and zero decimals. The first allocation mints 10 units to a partner wallet. Initial total supply and the partner’s balance are both zero.

An operation ID identifies the business request, a transaction hash identifies an on-chain transaction, and a receipt records its execution result. Linking these lets an operator trace a request through execution.

This is an example of integrating APIs and SDKs into your own system. The same operating approach applies to inventory or access rights by changing the asset identifier and right definition. When using RWA Ops or Fund Ops, map roles and records to the selected solution’s workflow.

1. Assign responsibilities and decision owners

Even in a small team, distinguishing operators, approvers and recovery decision owners makes handover easier. These are example responsibilities. If one person holds multiple roles, record which responsibility they exercised.

hazBase APIs, SDKs and contracts provide execution and query capabilities. The approval workflow, operation IDs, monitoring and business register below are operating controls implemented in the integrating application.

2. Create an environment and configuration register

Maintain separate registers for validation and production. Changing only a URL can leave addresses or permissions pointing to the wrong network, so check these settings together. Example values illustrate the register; they do not specify production endpoints or access terms.

3. Progress from validation to production

The sequence below is an example rollout. Recording evidence and open issues at each stage helps the business owner decide when to proceed, without assuming a fixed implementation timeline.

1. 1

   Select one initial workflow

   Start with the 10-unit allocation for ROBOT-A-001. Identify the requester, approver and screen where completion will be checked.

   Evidence to proceed

   Inputs, approval conditions and the completed register entry form one clearly described procedure.

2. 2

   Verify connectivity and reads

   Use the environment register to check chain, token address, decimals, cap, supply and recipient balance. Distinguish API-configured tokens from the contract’s actual state.

   Evidence to proceed

   Evidence identifies the correct target and initial balance 0, supply 0 and cap 1000.

3. 3

   Complete a limited write end to end

   Mint 10 units in an isolated validation environment. Trace approval, execution, events and register display under one operation ID. Integrate the example code at this stage.

   Evidence to proceed

   Issuance to the intended recipient, total supply 10, transaction evidence and the completed UI state agree.

4. 4

   Rehearse failure and recovery

   Exercise double-clicks, lost responses after submission, missing roles, paused contracts and interruption before register updates. Unresolved operations should remain traceable after a reload.

   Evidence to proceed

   No duplicate mint occurs; unknown outcomes are not resubmitted, and reconciliation resumes from the interruption point.

5. 5

   Begin production with limited scope

   Recheck production configuration and permissions, then start with agreed recipients and quantities. Have an operator observe the first run through reconciliation before expanding volume.

   Evidence to proceed

   The business owner and operator have reviewed reconciliation, monitoring, escalation contacts and recovery procedures.

4. Process a single allocation

Map the operator’s workflow to system actions as below. This allocation mints 10 new units. Transferring existing tokens is a different operation that reduces the sender’s balance, so record the operation type as well.

5. Retain operation records and processing states

The following is an application-side record, not a hazBase API request schema. Addresses and hashes are abbreviated. Keep agreement originals and personal data in access-controlled storage, linked through identifiers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "operationId": "ALLOC-2027-001",
  "operationType": "MINT",
  "assetId": "ROBOT-A-001",
  "agreementId": "AGR-2027-001",
  "chainId": 11155111,
  "tokenAddress": "<token address>",
  "recipient": "<approved recipient>",
  "amountAtomic": "10",
  "decimals": 0,
  "approvalRecordId": "APPROVAL-001",
  "status": "RECONCILED",
  "sourceEvent": {
    "transactionHash": "<transaction hash>",
    "blockNumber": 1234567,
    "blockHash": "<block hash>",
    "logIndex": 0
  },
  "reconciliation": {
    "allocatedAtomic": "10",
    "totalSupplyAtomic": "10",
    "asOfBlock": 1234567
  }
}

Store atomic quantities as strings to avoid rounding large values. Link the approved payload, stage timestamps, executor and attempt history. Handle conflicting payloads and concurrent processing with database uniqueness and concurrency controls. Merely storing an operation ID does not prevent duplicate execution.

6. Monitor and reconcile daily operations

Monitor whether accepted business operations complete, as well as API availability. The cadence and criteria below are examples. Set alert timing and retry intervals according to chain finality, workload and service limits.

Duplicate events and chain reorganizations

Identify indexed events by chainId, transactionHash and logIndex so replay does not apply them twice. Store both block number and hash at checkpoints. If the block hash changes, roll back derived register views for that range and replay it, keeping affected operations under review until resolved.

When comparing API and application balances, account for differences in read time and aggregation range. Use block-specific RPC/ABI reads when a fixed reference block is needed; comparing independently retrieved latest balances is insufficient to establish a discrepancy.

7. Respond to incidents

Identify the affected operation and establish how far it progressed before submitting anything new. A connectivity issue and suspected unauthorized activity may require different containment. Distinguish holding business requests from pausing a contract globally.

8. Manage releases and configuration changes

SDKs, applications, contracts and permissions are separate changes. Record the target, old and new values, affected workflows, validation method, executor and approver for each change.

After a change, reconcile a limited operation before expanding scope. If intake is held temporarily, distinguish in-flight and new requests and resume from the unresolved-operation list.

9. Complete the operational handover

Validate handover by having the operator investigate an operation ID and choose the next action, rather than relying on a walkthrough alone. The following evidence supports a go-live decision.

• Environment register: production connections, addresses, SDK/ABI versions, permissions and custody references are recorded.
• Successful-operation evidence: approval, transaction, confirmation decision and register display are traceable for the 10-unit allocation.
• Recovery evidence: double-clicks, missing responses and failed register updates were exercised without duplicate issuance.
• Monitoring and daily close: alert recipients, age thresholds, reconciliation checkpoints and owners of unresolved items are assigned.
• Continuity: backup operators, revocation, restore procedures, release revalidation and pause/resume decision owners are confirmed.

Information for technical support

Include timestamp and time zone, environment, chain ID, contract, SDK/application versions, operation ID, available transaction hashes, HTTP status/errorCode and expected versus actual results. Note whether a retry occurred and the last successful stage.

Redact private keys, OTPs, sessions, highTrustToken and customer personal data before sharing logs. Use request IDs for support tracing, separately from the application operationId used in duplicate-execution controls.