Skip to main content
A Shield Swap transaction combines local proof construction, network submission, token-program calls, finalization, and record extraction. Client code should report these as separate stages.

​
Build inputs

Format every Leo literal with its type suffix. Preserve field, u16, u32, u64, u128, i32, bool, and address distinctions. Struct field order and names must match Leo. Input records are supplied to the proving environment as decrypted record plaintext. Private scalar or field inputs, such as a blinding factor, must never be logged.

​
Prove and submit

The TypeScript TransactionExecutor supports a fast devnode path and a proof-generating path. Production integrations should report proving progress separately from broadcast and confirmation. At submission time, a locally valid proof can still fail finalization because public mappings changed after inputs were prepared. Common examples include a moved price, expired deadline, consumed record, changed pause state, or a new position boundary that invalidates insertion hints.

​
Confirm finalization

Do not treat a transaction ID as acceptance. Poll until the network reports accepted or rejected execution, then extract outputs from the accepted transition. Record outputs can be encrypted for different owners. A wallet should attempt decryption with the relevant view key and ignore investigator-owned records it cannot decrypt.

​
Retry rules

Retries fall into three classes:
  • Same transaction: continue polling when status is unknown.
  • Reprove with the same intent: rebuild deadline, quote, hints, records, and public state when the old transaction was rejected before consuming records.
  • Do not retry automatically: policy rejection, pause, freeze, unsupported token, arithmetic boundary, or uncertain record-spend status.
Before reproving a record-consuming action, confirm that the input record remains unspent. Submitting two independently proved transactions against the same record creates a race where at most one can succeed.

​
Output discipline

Persist all decrypted outputs before advancing application state. Mint and position mutations return a PositionNFT. Funding operations can return token change. Claims and collections return token records. Losing an accepted output record can make user funds difficult to discover even though they remain on chain.

​
Finalizer warnings

Leo 4.3.4 warns about checks and effects after Final.run() in several paths. Integrators should not attempt to compensate for contract ordering in the client. Operators and auditors must decide whether the token-call and rollback semantics make each site acceptable for the target network and token implementations.