Vechain SDK

The `Clauses.ts#transferToken()` function is designed to facilitate the transfer of VIP-180 tokens. The VIP-180 standard has been superseded by the ERC20 standard on Ethereum. [VIP-180](https://github.com/vechain/VIPs/blob/master/vips/VIP-180.md): > The VIP-180 has been superseded by the ERC20 standard on Ethereum. Development and usage of VIP-180 are strongly discouraged, and existing implementations are advised to migrate to ERC20. The function's parameter `amount` is of the `VTHO` type, the `VTHO.ts#of()` function restricts decimals to a maximum of 18 (`VTHO.WEI_FD`): ```typescript=54 public static of( value: bigint | number | string | FixedPointNumber, unit: Units = Units.ether ): VTHO { const fpn = value instanceof FixedPointNumber ? value : FixedPointNumber.of(value); return new VTHO( > fpn.div(FixedPointNumber.of(10n ** (VTHO.WEI_FD - BigInt(unit)))) ); } ``` The lack of support for token decimals greater than 18 can be an issue, as outlined in [EIP-20](https://eips.ethereum.org/EIPS/eip-20#specification) or [VIP-180](https://github.com/vechain/VIPs/blob/master/vips/VIP-180.md), this restriction is not imposed. Moreover, the restriction of `amount` to the `VTHO` type is misleading, since it is meant to represent any fungible token's amount.

The code snippet provided below shows an incorrect usage where the `generateKey()` function is being called with the `AES-GCM` algorithm. The comment on `Secp256k1.ts#L115` mentions that an ECDSA key pair should be generated, indicating a mismatch between the intended and implemented algorithm: ```typescript=115 // Generate an ECDSA key pair const cryptoKey = await global.crypto.subtle.generateKey( { name: 'AES-GCM', length: 256 }, true, ['encrypt', 'decrypt'] ); ```

The comment at the pointed locations states `// If the block is successfully fetched (not undefined or null), update the result and increment the block number`. However, the implementation only fetches the block in the `result`, without incrementing the block number: ```ts=258 if (block !== undefined && block !== null) { result = block; // Set the fetched block as the result } ```

The indicated methods return an empty object as a placeholder at the pointed location since they have not been implemented yet. However, the way unsupported methods are handled is different from the majority of the other unsupported methods. The unsupported methods explicitly return a message indicating the current method is unsupported, while the pointed methods return just an empty object. In this way, if those methods are called they could be interpreted as successfully executed even though they did not execute anything.

The function `HDKey.ts#isDerivationPathComponentValid()` is intended to validate individual components of a derivation path. The function aims to consider a path component as valid if it is in the format of a "number", "number'", or strictly "m" when the index is 0. However, the current implementation contains a flaw where paths that do not start with "m", but instead with a "number" or "number'", such as '1/0/1', are incorrectly deemed valid. This oversight can lead to incorrect path validation might allow improper derivation paths to be considered valid. Note: the BIP32 path starts with "m" ([BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)).

The function `request()` is returning directly `0x0` if `mustReturn0` is true and the method is `eth_getTransactionCount` without executing the request. Therefore, the flag `mustReturn0` transforms the function `request()` for that particular method to a no-op function.

The function returns a block based on the input `block` parameter. If the block is a string, it can be either `latest`, `earliest`, `pending`, `finalized`, `safe`, or a hex hash of a block `0x...`. However, if the input `block` is a `string` there is no guarantee it will be limited by those values as it can contain any string value. In that case, the function will return the value as is, thinking it is the hex number of a block.