Hi there, friends. Spring is here, and so is caver-js v1.8.0. It will make you laugh, rejoice and appreciate life. (NOT) But trust me, it does have a couple of new features that will make your developer life a bit easier.

If you didn’t know already, now you do: Klaytn supports Ethereum equivalence! And with caver-js v.1.8.0, you can start using Ethereum transaction types and the signatures that go with them. We also fortified our JSON-RPC arsenal for the klay namespace APIs.

## A Breakdown of What’s New in 1.8.0

In line with Klaytn’s pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. You can start using them with caver, via caver.transaction.

• Access lists are now available with TxTypeEthereumAccessList which was introduced with EIP-2930. The EthereumAccessList class is available in caver.transaction.ethereumAccessList as TxTypeEthereumAccessList.
• The transaction type TxTypeEthereumDynamicFee presented in the proposal EIP-1559 is also available. The EthereumDynamicFee class is available in caver.transaction.ethereumDynamicFee as TxTypeEthereumDynamicFee.

The newly added klay namespace API functions are now available with caver via caver.rpc.klay!

• caver.rpc.klay.getHeader
• caver.rpc.klay.getFeeHistory
• caver.rpc.klay.getMaxPriorityFeePerGas
• caver.rpc.klay.createAccessList

And you can use the ecsign function for the new Ethereum transaction types.

• Just know that you have to sign the transaction types EthereumAccessList and EthereumDynamicFee via ecsign to generate the ECDSA signatures.
• For the 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 the v in Klaytn contains chainId, making them incompatible.
• Find it here: keyring.ecsign

Klaytn SDK caver-java v1.8.0 Released

Hi there, lovely Java programmers. You are awesome, don’t let nobody tell you otherwise. We have some new features for caver-java v1.8.0, which are going to make your developer life a bit easier.

If you didn’t know already, now you do: Klaytn supports Ethereum equivalence! And with caver-java v.1.8.0, you can start using Ethereum transaction types and the signatures that go with them. We also fortified our JSON-RPC arsenal for the klay namespace APIs.

## A Breakdown of What’s New in 1.8.0

In line with Klaytn’s pursuit of Ethereum equivalence, Klaytn now supports Ethereum transaction types. You can start using them with caver, via caver.transaction.

• Access lists are now available with TxTypeEthereumAccessList which was introduced with EIP-2930. The EthereumAccessList class is available in caver.transaction.ethereumAccessList as TxTypeEthereumAccessList.
• The transaction type TxTypeEthereumDynamicFee presented in the proposal EIP-1559 is also available. The EthereumDynamicFee class is available in caver.transaction.ethereumDynamicFee as TxTypeEthereumDynamicFee.

The newly added klay namespace API functions are now available with caver via caver.rpc.klay!

• caver.rpc.klay.getHeader
• caver.rpc.klay.getFeeHistory
• caver.rpc.klay.getMaxPriorityFeePerGas
• caver.rpc.klay.createAccessList

And you can use the ecsign function for the new Ethereum transaction types.

• Just know that you have to sign the transaction types EthereumAccessList and EthereumDynamicFee via ecsign to generate the ECDSA signatures.
• For the 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 the v in Klaytn contains chainId, making them incompatible.
• Find it here:
• AbstractKeyring#ecsign()
• SingleKeyring#ecsign()
• MultipleKeyring#ecsign()
• RolebasedKeyring#ecsign()