shardeum/shardeum · error · Error

_base10BNParser: Unacceptable parameter value ${value} type

Error message

_base10BNParser: Unacceptable parameter value ${value}  typeof ${typeof value}

What it means

_base10BNParser converts a value to a BigInt but only accepts values that are already bigint or string. Any other type (number, null, undefined, object, BN instance) is rejected with this message. This is a strict input-sanitization guard, not a parsing failure of valid input.

Source

Thrown at src/utils/serialization.ts:75

  }

  throw new Error(`_base16BNParser: Unacceptable parameter value ${value}  typeof ${typeof value}`)
}

export const _base10BNParser = (value: bigint | DecimalString): bigint => {
  if (typeof value == 'string' && value.slice(0, 2) == '0x') {
    throw new Error('Parameter value does not seem to be a valid base 10 (decimal)')
  }
  if (typeof value === 'string' && isNaN(value as unknown as number)) {
    throw new Error('Parameter value does not seem to be a valid base 10 (decimal)')
  }
  if (typeof value === 'bigint') {
    return value
  }
  if (typeof value == 'string') {
    return BigInt(value)
  }
  throw new Error(`_base10BNParser: Unacceptable parameter value ${value}  typeof ${typeof value}`)
}

export const _readableSHM = (bnum: bigint, autoDecimal = true): string => {
  if (typeof bnum !== 'bigint') {
    throw new Error('Parameter value is not a valid bigint instance')
  }

  const unit_SHM = ' shm'
  const unit_WEI = ' wei'

  if (!autoDecimal) return bnum.toString() + unit_WEI

  const numString = bnum.toString()
  // 1 eth or 1 SHM === 10^18 wei
  // if wei value gets too big let's convert to SHM in a floating point precision.
  // 14 is where we set this threshold. hardcoded for now.
  if (numString.length > 14) {
    const floating_index = numString.length - 18

View on GitHub (pinned to 0c454caf06)

Solutions

1. Convert the value to a string or bigint before calling: use String(value) or BigInt(value)
2. Trace the offending field name printed in the message (the ${value}/${typeof value} tells you the type) and fix it at the source
3. If the value legitimately may be a number, add a typeof value === 'number' branch that converts via BigInt(Math.trunc(value)) or String(value)

Example fix

// before
const wei = _base10BNParser(someNumber) // typeof number -> throws

// after
const wei = _base10BNParser(BigInt(someNumber))
// or
const wei = _base10BNParser(String(someNumber))

if (typeof v !== 'bigint' && typeof v !== 'string') {
  v = String(v)
}
const bn = _base10BNParser(v)

const isParsable = (v: unknown): v is bigint | string =>
  typeof v === 'bigint' || (typeof v === 'string' && /^-?\d+$/.test(v))

When it happens

Trigger: Calling a Shardeum API (e.g. internal apply functions that serialize amounts) with a numeric JS number like 1000 instead of '1000' or 1000n, or passing null/undefined/BN.js objects into a field that eventually flows into _base10BNParser.

Common situations: Mixing BN.js or number literals into code paths migrated to native bigint; JSON payloads parsed with numbers instead of strings; default/missing config values (undefined) reaching amount fields.

Understand the failure class

Background: Invalid argument type errors: "must be of type string", "expected X, got Y", and ERR_INVALID_ARG_TYPE explained — this error's family across 15 libraries.

Related errors

• _base16BNParser: Unacceptable parameter value ${value} type
• Parameter value does not seem to be a valid base 10 (decimal
• Parameter value is not a valid bigint instance
• value overflow
• value underflow

AI-assisted analysis of shardeum/shardeum@0c454caf06 (2026-08-28). Data as JSON: /api/errors/0c389b831e2dffd9. Report an issue: GitHub.