Mode in which we want to sign the transaction. Ledger hardware app has certain limitations and it cannot sign arbitrary combination of all transaction features. The mode specifies which use-case the user wants to use and triggers additional validation on tx field.

See

Enumeration Members

ORDINARY_TRANSACTION: "ordinary_transaction"

Represents an ordinary user transaction transferring funds.

The transaction

  • should have valid path property on all inputs

  • must not contain a pool registration certificate

  • must contain key path stake credentials in certificates and withdrawals (no key or script hash)

  • must not contain collateral inputs

  • must not contain required signers

  • must contain only 1852 and 1855 paths

  • must contain 1855 witness requests only when transaction contains token minting/burning

The API witnesses

  • all non-null TxInput.path on inputs
  • all Withdrawal.path on withdrawals
  • all CredentialParams.path properties on certificates for Stake registering/deregistering/delegating certificate.
MULTISIG_TRANSACTION: "multisig_transaction"

Represents a transaction controlled by native scripts.

Like an ordinary transaction, but stake credentials and all similar elements are given as script hashes and witnesses are decoupled from transaction elements.

The transaction

  • must have path undefined on all inputs

  • must only contain output addresses given as TxOutputDestinationType.THIRD_PARTY

  • must not contain a pool registration or retirement certificate

  • must contain script hash stake credentials in certificates and withdrawals

  • must not contain collateral inputs

  • must not contain required signers

  • must contain only 1854 and 1855 witness requests

  • must contain 1855 witness requests only when transaction contains token minting/burning

The API witnesses

  • all given in SignTransactionRequest.additionalWitnessPaths
POOL_REGISTRATION_AS_OWNER: "pool_registration_as_owner"

Represents pool registration from the perspective of a pool owner.

The transaction

  • must have path=null on all inputs (i.e., we are not witnessing any UTxO)
  • must not have device-owned outputs
  • must not have outputs with datum
  • must have a single certificate, and it must be pool registration
  • must have a single owner of type PoolOwnerType.DEVICE_OWNED on that certificate
  • must not contain withdrawals
  • must not contain token minting
  • must not contain script data hash
  • must not contain collateral inputs
  • must not contain required signers
  • must contain only staking witness requests

These restrictions are in place due to a possibility of maliciously signing another part of the transaction with the pool owner path as we are not displaying device-owned paths on the device screen.

The API witnesses

  • the single PoolOwnerDeviceOwnedParams.stakingPath found in pool registration
POOL_REGISTRATION_AS_OPERATOR: "pool_registration_as_operator"

Represents pool registration from the perspective of a pool operator.

The transaction

  • should have valid path property on all inputs
  • must not have outputs with datum
  • must have a single certificate, and it must be pool registration
  • must have a pool key of PoolKeyType.DEVICE_OWNED on that certificate
  • must have all owners of type PoolOwnerType.THIRD_PARTY on that certificate
  • must not have withdrawals
  • must not contain token minting
  • must not contain script data hash
  • must not contain collateral inputs
  • must not contain required signers

Most of these restrictions are in place since pool owners need to be able to sign the same tx body.

The API witnesses

  • all non-null TxInput.path on inputs
  • PoolKeyDeviceOwnedParams.path found in pool registration
PLUTUS_TRANSACTION: "plutus_transaction"

Represents a transaction that includes Plutus script evaluation (e.g. spending from a script address).

The transaction

  • must not contain a pool registration certificate

Generated using TypeDoc