First outgoing transaction from SDK-created account fails until activated in Wallet

Klever Blockchain Developers
,
1

Hi Klever Team,

We’ve encountered an issue with new accounts created via @klever/sdk-node.

Symptom:

Addresses created with new Account() can successfully receive incoming transactions, but the first outgoing transaction sent via SDK often fails - it does not broadcast or index (responses like “fetch failed” / “no hash”). After sending just one outgoing transaction from the Klever Wallet app, subsequent SDK transactions work consistently and without issues.

Request:

Could you please clarify what needs to be taken into account when building the very first transaction through the SDK (e.g. account initialization, correct nonce handling, ChainID/Version/fees, node-side account status, etc.), so that it works immediately without requiring this initial “activation” from the Wallet app?

Thanks a lot for your support!

2

Guys, could you please take a look at this? @Nicollas @Duka

3

The issue was caused by using an incorrect ChainID / low-level transaction packing combined with a hidden provider fallback to an inactive domain. The fix was to explicitly set providers, use the correct ChainID from the SDK, rely on high-level transaction builders, and handle nonce properly.

4

Please fix the fallback to the outdated domain in the next SDK update, so developers don’t run into this issue and don’t need manual workarounds. @Duka

5

Hello my friends, the @Blockchain team is aware about it and checking. We’ll get back as soon as we get a response to y’all.

6

Hello @Sovkosov_Ignat!
Thank you for reaching out. To better assist you, could you please provide the following information:

SDK Version
Which version of @klever/sdk-node are you currently using? This issue often occurs with outdated versions, as we’ve recently replaced deprecated domains in the latest releases.

Possible Causes
Your issue might be related to one of these common scenarios:

  • Outdated SDK: The deprecated domains have been fixed in recent versions, so updating might resolve your issue
    Chain Mismatch: The “wrong chain ID” error typically occurs when:

  • Your provider is configured for testnet but the transaction targets mainnet (or vice versa)
    Note: Mainnet is the default chain selection

Information Needed
To help us investigate further, please share:

  • Complete version listing of all relevant dependencies

    The code snippet that resolved your issue
    Any error messages you’re seeing

This will help us test the scenario internally and potentially improve the SDK if needed.
Let me know if you need any clarification or have additional questions!

1 Like
7

Hello @Enebish , could you help us support your team by asking @Sovkosov_Ignat to provide the requested information, please?

1 Like
9

Hello Nicollas!

  • SDK version: @klever/sdk-node 2.4.1

  • Network/providers: Mainnet only. We explicitly set providers to https://api.mainnet.klever.org and https://node.mainnet.klever.org via utils.setProviders(…) before each Account creation (no deprecated .finance domains).

  • Concurrency: Per-sender serialization via Bottleneck (minTime=800ms). No parallel sends from the same address; nonces are strictly sequential.

  • Code snippet (stable for “warm” addresses):

const { Account, TransactionType, utils } = require('@klever/sdk-node');

utils.setProviders({
  api: 'https://api.mainnet.klever.org',
  node: 'https://node.mainnet.klever.org',
});

const account = new Account(PRIVATE_KEY);
await account.ready;
await account.sync();

const unsigned = await account.buildTransaction([
  { type: TransactionType.Transfer, payload: { amount: AMOUNT_RAW, receiver: TO, kda: 'KLV' } }
]);

const signed = await account.signTransaction(unsigned);
const resp = await account.broadcastTransactions([signed]);
  • Minimal repro (problem on first outgoing tx from a “cold” programmatically created wallet):
utils.setProviders({ api, node });
const a = new Account(COLD_PK); await a.ready;
// fresh nonce from API (chain shows 0), we use nonce=1:
const unsigned = await a.buildTransaction(
  [{ type: TransactionType.Transfer, payload: { amount: 1, receiver: TO, kda: 'KLV' } }],
  undefined,
  { nonce: 1 }
);
const signed = await a.signTransaction(unsigned);
const resp = await utils.broadcastTransactions([signed.toBroadcast?.() ?? signed]); // node returns hash
// polling /v1.0/transaction/{hash} for ~10s → not indexed

  • Errors observed:

    • account.broadcastTransactions: “fetch failed” when sdkNonce=0 on a cold address.
    • utils.broadcastTransactions: node returns a hash, but the tx never gets indexed within 10s.
    • Example (mainnet) cold address: klv1psh57lrp7l3z5l2472zmj0wg7evzngznrt3jf6e0exc9yseks84qhzdtvw
      • Example unindexed hash: fda688a5f8b292cf7e3c317e53b5e63b3df767ba9f4b3e1aacb78f8dc957e089

  • Dependency versions (relevant):

{
  "@klever/sdk-node": "2.4.1",
  "axios": "1.8.4",
  "bottleneck": "2.19.5",
  "dotenv": "16.4.7",
  "telegraf": "4.16.3",
  "sqlite3": "5.1.7",
  "express": "4.21.2"
}

Happy to share a full single-run log (preflight, sdkNonce, payload head, hash, indexing polling) if useful. @Nicollas @Duka

10

@Duka @Nicollas I hope for your help, guys

11

Hello @Sovkosov_Ignat!

“Fetch Failed” Error Fix

Thanks for the examples! We found the issue regarding the “fetch failed” error when nonce=0, and we will soon deploy a version for the @klever/sdk-node package with this fix.

“Cold” Wallet Issue Explanation

Regarding the issue with the “Cold” wallet: in your example, as you noted in the comment:
// fresh nonce from API (chain shows 0), we use nonce=1

What Happened:

  • A Tx1 with nonce=1 was broadcasted while the account had nonce=0
  • This means Tx1 would be stuck in the node transaction mempool waiting for a transaction with nonce=0
  • After broadcasting a transaction with nonce=0, both transactions would be processed and then indexed

Root Cause:

Since you were prevented from sending a transaction with nonce=0 because of the “fetch failed” issue, you couldn’t establish the proper nonce sequence.

Solution:

With the upcoming fix, you should be able to send the first transaction using the @klever/sdk-node package without encountering the nonce=0 fetch error.

4 Likes
12

Hello @Sovkosov_Ignat !

We have released version 2.4.2 of @klever/sdk-node with the fix. Could you please try again and let us know if this resolves your issue?

1 Like
13

@Romulo_Siebra Thanks a lot for the quick fix and the feedback :raising_hands:
I’ll get back to you as soon as I’ve tested the updated SDK

1 Like
14

Hello @Romulo_Siebra

We’re seeing a consistent case where a broadcasted transaction hash isn’t available via the API within 5 seconds.

Environment:

Repro steps:

  1. Load wallet from PEM (SDK-generated).
  2. Send 1 KLV to a target address.
  3. Receive tx hash on broadcast.
  4. Poll GET /v1.0/transaction/{hash} every 500 ms for up to 5 s.

Expected:

  • Transaction indexed within ≤5 s.

Observed:

  • API responds 404 (not_found) during the 5 s window; sender nonce stays unchanged.

Example:

  • Hash: 89354657700c90f473bdf7b420e0501322f7c3af5f3baf8034a92fc5d53ede82
  • Log: [Index] HTTP 404 | body: {“data”:null,“error”:“cannot find transaction in database”,“code”:“not_found”}…

Could you please take a look on the API/indexer side or advise next steps? Happy to share full logs if helpful. Thank you!

15

Hello @Sovkosov_Ignat

I investigated the transaction with hash 89354657700c90f473bdf7b420e0501322f7c3af5f3baf8034a92fc5d53ede82 in the node’s transaction pool. The transaction was submitted with nonce=2, this appears to be the source of the issue.

Transaction Details:

  • Hash: 89354657700c90f473bdf7b420e0501322f7c3af5f3baf8034a92fc5d53ede82

  • Sender: klv13gxjqtdwk4jcd2w4x33rdn3gmsm4tf72u2285reaupvs4nccskjq78epsj

  • Submitted nonce: 2

Current Account Nonce Status:
When querying the node directly for this address’s nonce, I get:

{
 "data": {
    "firstPendingNonce": 2,
    "nonce": 0,
    "txPending": 3
  }
}

The Problem:
The account currently has 3 pending transactions in the pool, with firstPendingNonce: 2. This indicates there’s a nonce gap in the transaction sequence.

Solution:
To resolve this issue and allow your transaction to be processed, you need to:

  1. Submit a transaction with nonce=0 first

  2. Then submit a transaction with nonce=1

  3. Only after these are processed will your transaction with nonce=2 be executed

The blockchain requires transactions to be processed in sequential nonce order. Any gaps in the sequence will cause subsequent transactions to remain pending indefinitely.

Please try this solution and let me know if it resolves the issue.

3 Likes