This repository has been archived by the owner on Jul 23, 2024. It is now read-only.
Releases: klaytn/caver-js
Releases · klaytn/caver-js
Release v1.8.2-r.c2
Release v1.8.1-rc.7
Release v1.8.1-rc.6
Release v1.8.1-rc.5
Release v1.8.1-rc.4
v1.8.1-rc.4 Release Notes
Breaking Change
- To create a transaction, you must use the
create
function, not the constructor since v1.8.1-rc.4.
If you usenew caver.transaction.xxx({...})
to create a transaction instance, usecaver.transaction.create({...})
instead.
Fixes
- Fixed a bug in klaytnCall that is declared as a static variable and used publicly when using multiple Caver instances. In case of using multiple instances, since static variables are overwritten based on klaytnCall of the latest Caver instance, when signing a transaction in an instance other than the latest Caver, the endpoint to which the rpc call should be sent is changed to the provider of another instance has been modified. (#534)
Release v1.8.1-rc.3
v1.8.1-rc.3 Release Notes
Fixes
- Fixed a test case to send
gasPrice
field when send/sign a transaction via a keystore existed in Klaytn Node. (https://github.com/klaytn/caver-js/pull/622)
Release v1.8.1-rc.2
Release v1.8.1-rc.1
v1.8.1-rc.1 Release Notes
Improvements
- Updated the abi and byte code of the KCT contracts with klaytn-contracts. (https://github.com/klaytn/caver-js/pull/616)
Release v1.8.0
v1.8.0 Release Notes
What's New
-
- In line with Klaytn's pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. But what is an update without SDKs? You can start using these transactions with caver, via
caver.transaction
. - Access lists are now available with
TxTypeEthereumAccessList
which was introduced with EIP-2930
* TheEthereumAccessList
class is available incaver.transaction.ethereumAccessList
asTxTypeEthereumAccessList
. - The transaction type
TxTypeEthereumDynamicFee
presented in the proposal EIP-1559 is also available
* TheEthereumDynamicFee
class is available incaver.transaction.ethereumDynamicFee
asTxTypeEthereumDynamicFee
.
- In line with Klaytn's pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. But what is an update without SDKs? You can start using these transactions with caver, via
-
The newly added
klay
namespace API functions are now available with caver viacaver.rpc.klay
! -
You can use the
ecsign
function the new Ethereum transaction types.- The nitty-gritty: You have to sign the transaction types
EthereumAccessList
andEthereumDynamicFee
viaecsign
to generate the ECDSA signatures. - If you are inquisitive, the
v
in the signature values {v, r, s} for the new Ethreuem transaction types is a parity (0 for even, 1 for odd) of the y-value of the Secp256k1 curve, whereas thev
in Klaytn containschainId
, making them incompatible. - Find it here: keyring.ecsign
- The nitty-gritty: You have to sign the transaction types
Release v1.8.0-rc.1
v1.8.0-rc.1 Release Notes
What's New
-
- In line with Klaytn's pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. But what is an update without SDKs? You can start using these transactions with caver, via
caver.transaction
. - Access lists are now available with
TxTypeEthereumAccessList
which was introduced with EIP-2930
* TheEthereumAccessList
class is available incaver.transaction.ethereumAccessList
asTxTypeEthereumAccessList
. - The transaction type
TxTypeEthereumDynamicFee
presented in the proposal EIP-1559 is also available
* TheEthereumDynamicFee
class is available incaver.transaction.ethereumDynamicFee
asTxTypeEthereumDynamicFee
.
- In line with Klaytn's pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. But what is an update without SDKs? You can start using these transactions with caver, via
-
The newly added
klay
namespace API functions are now available with caver viacaver.rpc.klay
! -
You can use the
ecsign
function the new Ethereum transaction types.- The nitty-gritty: You have to sign the transaction types
EthereumAccessList
andEthereumDynamicFee
viaecsign
to generate the ECDSA signatures. - If you are inquisitive, the
v
in the signature values {v, r, s} for the new Ethreuem transaction types is a parity (0 for even, 1 for odd) of the y-value of the Secp256k1 curve, whereas thev
in Klaytn containschainId
, making them incompatible. - Find it here: keyring.ecsign
- The nitty-gritty: You have to sign the transaction types