Skip to main content

FAQ

Smart contract call failure

If you receive a mandatory-script-verify-flag-failed error when broadcasting a transaction, it means that one or more inputs calling a contract fails.

There are several possibilities for the failure.

Script evaluated without error but finished with a false/empty top stack element is the most common one. It means one of assert fails.

Another common error is Signature must be zero for failed CHECK(MULTI)SIG operation, which means the signature is invalid in checkSig or checkMultiSig.

You need to debug the contract.

Broadcast double-spending transactions

You could get two different errors when broadcasting a double-spending transaction, depending on the status of the transaction you're trying to double-spend.

  • If the transaction you're trying to double-spend is still unconfirmed and in the mempool, the error would be txn-mempool-conflict.

  • If the transaction is already mined into a block and confirmed, the error would be Missing inputs.

1) for developers

If you encounter these errors when running code, e.g., testing on testnet, it is likely because the provider you are using fails to update your UTXO in time and return UTXOs that have already been spent when you request. Using these UTXOs that have been spent to build transactions will result in a double-spending. This situation is transitory and is caused by the provider not updating UTXO set timely due to, e.g., the provider's server overloading due to heavy blockchain traffic.

To fix this issue, you generally only need to wait a few seconds and retry. If it still persists, you can also increase the time interal between sending consecutive transactions, for example, sleep for some time after sending transactions before requesting the UTXO again, so that the provider has enough time to update the UTXO set:

// ... contract call #1

await sleep(2000) // Sleep for 2 seconds

// ... contract call #2

2) for dApp users

If you encounter these errors when using a dApp, it is likely because the state of dApp's contract has been changed by another user, who is interacting with the dApp at the same time. You are interacting with the contract instance that is stale, resulting in a double-spending.

To fix this issue, you usually only have to wait a few seconds, your local dApp will automatically obtain the latest contract state if it has subscribed to contract events; otherwise you have to manually refresh the browser and try again.

Input string too short

If you do not set the PRIVATE_KEY environment variable in .env file before deploying a contract, you would get an Input string too short error.

Please follow this guide to generate a new private key or export the private key from your Sensilet wallet, then fund the private key's address with our faucet.

No sufficient utxos

If you don't fund your private key's address before deploying a contract, you would get a No sufficient utxos error.

Please fund your address with our faucet first.

Bad CPU type in executable

This can occur on a Mac with Apple silicon (ARM processor), since the sCrypt compiler is based on Intel processor. Install Rosetta with the following command.

softwareupdate --install-rosetta --agree-to-license