Skip to content

v9.3.0

Latest

Choose a tag to compare

@joticajulian joticajulian released this 11 Aug 17:21
· 2 commits to main since this release

v9.3.0 (2026-08-11)

πŸš€ Features

  • New Provider helpers to read database objects via system calls: invokeGetObject, invokeGetNextObject, invokeGetPrevObject, and invokeGetManyObjects.

v9.2.0 (2026-01-25)

πŸš€ Features

  • Multicall class: This class was created to be able to make multiple read operations in a single http call. It uses the Multicall contract which was designed for this purpose. See Multicall contract.

v9.1.1 (2025-12-15)

πŸ› Bug Fixes

  • Import google protobuffer descriptor by default in all ABIs. This update fixes the issue presented in recent versions of NextJS, that throws an error if the ABI does not include this descriptor.

v9.1.0 (2025-01-29)

πŸš€ Features

  • Export nicknames abi
  • Minor updates in the documentation

πŸ› Bug Fixes

  • Fix issue in utils.formatUnits for 0 decimals
  • Fix: Use byTransactionId by default in the wait function of Provider.sendTransaction

v9.0.0 (2024-12-16)

πŸš€ Features

  • breaking change: Provider.invokeSystemCall returns undefined instead of throwing an error if the response from the RPC node is empty.
  • breaking change: The Provider.wait function now uses byTransactionId by default since it is more accurate. This function has also been improved by checking that the block is part of the main fork. If you are connecting to an RPC node that does not support the "transaction store microservice" consider changing the type to byBlock.
  • breaking change: The ABI now uses events[name].type to define the protobuffer type of the event (in previous versions this was defined as events[name].argument). The library still supports events[name].argument, but this will be removed in future versions.
  • Adding burn to token and NFT ABIs in utils.
  • The documentation has been updated.

v8.1.0 (2024-11-18)

πŸš€ Features

  • New Provider.invokeGetContractAddress to resolve the address to a system contract.
  • We have defined a ProviderInterface and we use it in all classes. This interface is less
    restrictive than the Provider Class which has more functions. Then, the ProviderInterface
    is ideal to develop other implementations for the Provider Class.
  • The documentation has been updated.