The WalletTestAPI is an extended WalletAPI for interacting with a Cardano wallet in a Test Environment.

Hierarchy

Methods

  • Experimental

    A list of UTXO to use as collaterals

    Returns Promise<TxOutRef[]>

    Remarks

    This method came from the CIP-30 spec but it might not be applicable to all wallets implementations (Lucid for example) so this is currently marked as experimental until we make sure we need it. Also, the rest-client allows for optionally set the collateral and empiric evidence shows that our current coin selection mechanism works better if it can guess the collateral utxo instead of us providing it.

    See

  • Experimental

    A helper around getTokens that returns only the lovelace ammount.

    This is marked experimental as it is redundant to have both getTokens and getLovelaces for the implementors. We could offer this as a function on top of getTokens, the only reason to have it here is for possible performance improvements.

    Moreover, this function is useful in the context of DApps to show the user how much lovelaces they have but not for the context of creating or balancing Marlowe transactions.

    Returns Promise<bigint>

  • Experimental

    Get the tokens available to the wallet.

    Returns Promise<Token[]>

    Remarks

    The Token type here refers to the runtime-core type and not the language-core-v1 Token.

  • Experimental

    Returns a flag that indicates wether the wallet is connected to the Mainnet or a Testnet.

    Returns Promise<boolean>

    Remarks

    The Network Id returned by CIP30 Interface doesn't provide information on which Testnet Network the extension in configured. See github issue

    When using Lucid instead, you can get the protocol parameters.

    This method is marked as experimental as we might wan't to remove it from the WalletAPI and rely to whatever information is available in the actual implementation

    See

    Github discussion on wallet package scope

  • Experimental

    Ask the wallet to sign a transaction

    Parameters

    • tx: string

      A CBOR encoded transaction

    Returns Promise<string>

    The signed transaction or throws

    Throws

    Error if there was a problem signing the transaction

    Remarks

    CIP30 expects a CBOR Transaction, which consists of <txBody + witness>. The Marlowe runtime default flow returns just the txBody, to get what CIP30 expects you need to pass an Accept header when creating a contract or applying inputs. The header is Accept "application/vendor.iog.marlowe-runtime.contract-tx-json" and it is automatically included in the @marlowe.io/runtime-* packages.

  • Experimental

    Waits for a transaction to be confirmed.

    Parameters

    • txHash: string

      the transaction hash

    Returns Promise<boolean>

    true if the transaction is confirmed, false otherwise

  • Wait if the runtime is behind the current slot of the wallet Test.

    Parameters

    Returns Promise<void>

    Remarks

    Wallets and Marlowe Runtimes are potentially connected to 2 differents Cardano Nodes. In our test environment, in order to avoid inconsistencies when building Tx, we need to provide some synchronization mechanism. Depending on which component is performing the last Tx, we need to wait for the other one to catch up to have a consustent behaviour.