Experimental
Returns an address to be used as Change Address when balancing transactions.
This method was taken from the CIP-30 spec but it might not be applicable to all wallets implementations, Lucid for example offers a single address method.
Experimental
A list of UTXO to use as collaterals
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.
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.
Experimental
Some wallets have a single address and some wallets derive multiple addresses from a single root private key. This method helps to keep track of the used derived addresses.
Same remark as getChangeAddress
Experimental
Returns a flag that indicates wether the wallet is connected to the Mainnet or a Testnet.
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
Execute a Provisioning Scheme from this current WalletTestAPI instance for the simulated participants of a Test:
Experimental
Ask the wallet to sign a transaction
A CBOR encoded transaction
The signed transaction or throws
Error if there was a problem signing the transaction
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.
Wait if the runtime is behind the current slot of the wallet Test.
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.
The WalletTestAPI is an extended WalletAPI for interacting with a Cardano wallet in a Test Environment.