A successful route is not proof of a credited vault deposit
A cross-chain vault deposit has more than one result to verify. The source transaction must be submitted, funds must reach the destination, and the vault must credit the intended recipient. A source transaction hash cannot establish all three.
When a Trustware route includes a destination contract call, check the route's terminal status and then verify the action against the destination contract. The route status reports the provider's aggregate result; it does not provide a separate destination-call status field.
That distinction matters whenever your application issues credit, updates a position, or unlocks another action after a deposit.
What each signal tells you
| Signal | What it establishes | What it does not establish by itself |
|---|---|---|
| Source transaction hash | A transaction can be located and tracked on the source chain | Destination settlement or vault credit |
Route status success |
The route reports successful completion | The intended beneficiary received the expected vault credit |
| Verified destination amount | The destination amount was checked on chain | The vault issued the correct shares or updated the correct position |
| Destination contract state tied to the transaction | Evidence of the application's intended outcome | A generic guarantee that every future route will behave identically |
Use the status reference for route fields and the vault walkthrough for destination verification.
1. Define what a successful deposit means
Before submitting a route, decide which contract state proves success for your application.
For a simple balance-based vault, that may be an increase in the recipient's credited balance. For a share-issuing vault, it may be the expected shares or a deposit event identifying the recipient. A margin account may require checking a position or collateral record instead.
Do not assume a token amount and a share amount are interchangeable. The check must follow your contract's accounting rules, including any conversion, fees, or rounding.
Record the intended beneficiary, destination contract, asset, and expected outcome with the transaction record. These are the facts your application will reconcile later.
2. Track the executed route
Receipt submission connects a broadcast transaction to route tracking. Direct REST integrations submit the source transaction hash explicitly. SDK helpers differ: follow the receipt behavior documented for the helper you use rather than posting a second receipt automatically.
For example, sendReviewedRoute handles receipt submission and returns the intent to poll. Use its returned sent.receipt.intentId, not an earlier reviewed route's intent. The headless SDK reference describes that distinction.
Keep the route intent and transaction hashes associated with your application's deposit record. If route preparation changes before signing, the record must follow the transaction that was actually sent.
3. Check status explicitly
A resolved polling call is not necessarily a successful route. The documented pollStatus behavior also resolves for failure and polling timeout. Check the returned status before proceeding.
If the route is still unresolved, show that state rather than crediting the user optimistically. If it fails, inspect the available evidence before offering a retry. Starting another transaction without understanding the first can create a second payment rather than repair the original one.
Once the route reports success, continue to the destination check instead of treating that status as the end of vault accounting.
4. Verify the destination contract outcome
The vault guide demonstrates reading the recipient's contract balance before building the route and again after settlement. That works as a starting pattern for contracts whose accounting can be checked through a balance change.
For production accounting, also consider concurrent deposits and withdrawals. A balance difference can contain activity from more than one transaction. Where the contract exposes suitable events or transaction-specific records, use them to attribute the change to the deposit you are checking.
Check the contract's own units and beneficiary semantics. If it issues shares, verify shares under that contract's rules rather than comparing them directly with the input-token amount.
Use the destination transaction hash to investigate a mismatch. If the expected credit is absent, keep the deposit in a review state instead of displaying a completed vault deposit.
5. Distinguish an estimated amount from a verified amount
A destination amount field can still contain a pre-trade estimate. In the documented REST status response, to_amount_wei is exact only once landed_amount_verified is true. The SDK vault guide refers to the amount as toAmountWei and uses the same verification flag.
Check the flag before using the amount to drive automatic actions. Even a verified routed amount does not replace the vault-specific accounting check: received tokens and credited shares answer different questions.
6. Handle fallback as a separate outcome
Some providers support toFallbackAddress when a destination call fails. Not every provider implements it, and route status alone does not tell you whether a fallback ran.
If your integration uses fallback, inspect the relevant destination execution, contract state, and fallback address balance. Funds arriving at a fallback address is not the same outcome as funds entering a vault for the intended recipient.
See fallback behavior for the documented limitations. Do not promise automatic recovery without confirming the selected route's behavior.
Keep enough evidence for reconciliation
A useful application record includes:
- Your internal deposit reference and intended beneficiary.
- The executed route's intent ID.
- Source and destination chains and transaction hashes, when available.
- Route status and the destination-amount verification flag.
- The contract-specific evidence used to confirm or reject credit.
- Request and provider correlation IDs where available for support.
These are application design recommendations, not a claim that Trustware automatically maintains your vault ledger. Your application owns the business decision to recognize credit and trigger downstream actions.
Frequently asked questions
Can I credit a vault deposit when the source transaction confirms?
Not on that evidence alone. Source-chain confirmation does not establish destination settlement or the vault's accounting result.
Does route success prove the destination call succeeded?
Not by itself. Trustware's documentation requires checking the destination contract because there is no separate destination-call status field.
Is a verified destination amount enough?
It confirms the routed amount was checked on chain. You still need to verify the vault's intended credit, shares, or position for the correct beneficiary.
Is a before-and-after balance check always sufficient?
No. It must match the contract's accounting model, and concurrent activity can complicate attribution. Use transaction-specific evidence where the contract provides it.
Make completion an accounting decision
A completion screen should reflect the outcome your application promised, not just the earliest successful transaction signal. Follow the vault verification walkthrough and status reference to connect route tracking to your own destination checks.