> ## Documentation Index
> Fetch the complete documentation index at: https://shield.fi/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction execution

> Proving, submission, finalization, outputs, and retries.

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.