Error: not enough coins to fit the target

Sway
1

Essentially, I have a Fungible contract that acts as a “native asset wrapper” that handles minting and burning of assets. The mint method is as follows:

#[storage(read, write)]
fn mint(recipient: Identity, amount: u64) {
    let asset_id = AssetId::new(contract_id(), ZERO_B256);

    let supply = storage.total_supply.get(asset_id);

    storage
        .total_supply
        .insert(asset_id, supply.try_read().unwrap_or(0) + amount);

    mint_to(recipient, ZERO_B256, amount);
}

and then a generic contract with the following method:

#[payable]
#[storage(read, write)]
fn do_something() {
     // do some random stuff here
}

within the Typescript SDK, I’m doing the following:

[deployer, user1] = await getWallets() // creates two wallets funded with ETH in the local node

...
// deployer deploys both contracts: FungibleContract and TestContract

// balance before: 0
await FungibleContract.functions.mint(toIdentity(user1.address), 10_000).call()
// balance after: 10_000

// issue is here:
TestContract.account = user1 // prank as user1
await TestContract.functions.do_something()
    .callParams({ forward: [10, getAssetId(FungibleContract) })
    .txParams({ variableOutputs: 1 }) // this doesn't solve the error unfortunately
    .call()

I’ve verified the getAssetId(contract) works well (I’m able to query the balance well). I’ve also verified I have sufficient ETH and FungibleContract assets in both deployer and user1 within the local node.

When I remove the TestContract.account = user1 line (so effectively, the deployer is calling the contract instead of user1), I don’t get the error Error: not enough coins to fit the target.

I know this error has something to do with UTXOs, but can’t wrap my head around this particular issue. Any suggestions?

This is the full error:

Error: not enough coins to fit the target: 
{
  "response": {
    "data": null,
    "errors": [
      {
        "message": "not enough coins to fit the target",
        "locations": [
          {
            "line": 2,
            "column": 3
          }
        ],
        "path": [
          "coinsToSpend"
        ]
      }
    ],
    "status": 200,
    "headers": {}
  },
  "request": {
    "query": "query getCoinsToSpend($owner: Address!, $queryPerAsset: [SpendQueryElementInput!]!, $excludedIds: ExcludeInput) {\n  coinsToSpend(\n    owner: $owner\n    queryPerAsset: $queryPerAsset\n    excludedIds: $excludedIds\n  ) {\n    ...coinFragment\n    ...messageCoinFragment\n  }\n}\n\nfragment coinFragment on Coin {\n  __typename\n  utxoId\n  owner\n  amount\n  assetId\n  maturity\n  blockCreated\n  txCreatedIdx\n}\n\nfragment messageCoinFragment on MessageCoin {\n  __typename\n  sender\n  recipient\n  nonce\n  amount\n  assetId\n  daHeight\n}",
    "variables": {
      "owner": "0xe373620c9fdae7e928ee42001314bf8ab9638cd82a61f4e19a4e27133a419f7b",
      "queryPerAsset": [
        {
          "assetId": "0x3581afea00c726328e2f455738f46f002c89db9b5a1713779988cdff8b5f4150",
          "amount": "1"
        },
        {
          "assetId": "0x0000000000000000000000000000000000000000000000000000000000000000",
          "amount": "1"
        }
      ],
      "excludedIds": {
        "messages": [],
        "utxos": []
      }
    }
  }
}

Additionally, this error could be more user-friendly.

4

@nedsalk @calldelegation @IGI-111 @Dhaiwat10

5

@anderson @Torres-ssf ?

6

This part seems hacky:

TestContract.account = user1

Are you generating types for your contract using typegen?

Please try creating a new instance for user1, and see if the problem is resolved.

1 Like
7

thanks for this.

the issue was in my implementation. While I did mention this line above: TestContract.account = user1 , I didn’t actually use it in my implementation (i had multiple contracts within the same test context, and missed using this for the main contract).

Effectively, while user1 had the coins, deployer did not. Not using the TestContract.account = user1 line above was still using the deployer context (which did not have sufficient coins).

Apologies, and thanks for pointing me in the right direction @anderson!

3 Likes