package.json
file should exist on the same install path. If it does not exist, package.json
can be generated via npm init
.keystore file
to send KLAY with a value transfer transaction. The keystore file can be created in Klaytn Wallet. If you need KLAY for testing, you can get Baobab testnet KLAY from the Klaytn Wallet.test.js
file created in the working directory.keys
property inside, and this keys
is implemented as an array to store multiple private keys.keys
property defined in RoleBasedKeyring is implemented as a two-dimensional array (empty keys
will look like [ [], [], [] ]
) that can include multiple keys for each role. The first element of the array is filled with the private key(s) to be used for roleTransactionKey
, the second element the private key(s) to be used for roleAccountUpdateKey
, and the third element the private key(s) to be used for roleFeePayerKey
.keyring.address
and keyring.key
.caver.wallet.keyring.createFromPrivateKey
, like the result of caver.wallet.keyring.generate
above, is a SingleKeyring instance with an address defined inside it and a [PrivateKey] instance in keyring.key
._keys
has multiple PrivateKey instances in the array. Member variables defined inside the instance can be accessed through keyring.address
and keyring.keys
.caver.wallet.keyring.createWithRoleBasedKey
is used instead. Each array element represents a role described in RoleBasedKeyring. The example below shows how to create a RoleBasedKeyring instance from different keys for each role.roleTransactionKey
, has three PrivateKey instances, and the second element, roleAccountUpdateKey
, has one PrivateKey instance. And the last element of the array, roleFeePayerKey
, has two PrivateKey instances.caver.wallet
after adding it to caver.wallet
.caver.wallet.newKeyring
is executed with a private key, a Keyring instance with one private key is created and added to caver.wallet
. For multiple private keys, a Keyring instance with multiple private keys is created. When passing one or more private keys for each role as arguments, a Keyring instance with a different private key(s) for each role is created and also added to the caver.wallet
.caver.wallet.add
or caver.wallet.newKeyring
returns a Keyring instance after adding it to caver.wallet
.caver.wallet.sign
function to sign.caver.wallet
, you can sign the transaction through transaction.sign
function.caver.rpc.klay.sendRawTransaction
.caver.wallet
, creates a transaction, and signs the transaction through caver.wallet.sign
.0x{RLP-encoded string}
with the value of rlpEncoded
above.caver.wallet
, see the example below.transactionHash
field is defined inside the receipt object. You can use caver.rpc.klay.getTransactionReceipt RPC call with receipt.transactionHash
to query the receipt of a transaction at any time from the network after the transaction is included in a block. The example below shows how to get a receipt using the caver.rpc.klay.getTransactionReceipt RPC call.status
of the receipt. For the details of the return values, see caver.rpc.klay.getTransactionReceipt. If a transaction is failed, you can check more about the error in txError
of the receipt. For more information about txError
, see txError: Detailed Information of Transaction Failures.feePayerSignatures
to the RLP-encoded string (rawTransaction
) signed by the transaction sender. If caver.wallet
also has the fee payer's key, the fee payer's signature can be injected into feeDelegatedTx
by calling caver.wallet.signAsFeePayer(feePayer.address, feeDelegatedTx)
. Otherwise, the fee payer has to create a feeDelegatedTx
from the RLP-encoded string signed by the sender and add the fee payer's sign onto it, as illustrated below. If you want to run the below example, replace 0x{RLP-encoded string}
with the value of rlpEncoded
above.0x{RLP-encoded string}
with the RLP-encoded string output of the example code above.newKeyring
through caver.wallet.updateKeyring(newKeyring)
. Once it is updated, the signing will be done by the newly updated private key(s).account
field inside the transaction object, the left rest of the updating process is just the same as the above example.AccountKey
type that defines the key to use for each role.account
field of the transaction.