🔐Default Ed25519 transactions
Solana compatible accounts

Create and send default transaction
Keypair creation process

Generate keypair
Output:
Tricks with BIP-44
By default, you get the new mnemonic and key pair with m/44'/7331'/0'/0' path. But, to generate many accounts from a single seed do this:
Get the mnemonic from the first generation
Change the path to 1,2,3... to build the HD chain of accounts
For example:
Get the first keypair in future chain:
Output:
For the first pair in future chain of accounts we don't set the mnemonic and BIP-44 path. Mnemonic will be randomly generated and path will be m/44'/7331'/0'/0'. The last parameter is the password that will be used to get the seed from your mnemonic.
That's why - choose the password with the high entropy, ommiting typical passwords from well known wordlists to make brute force impossible. Also, DON'T SHARE YOUR MNEMONIC PHRASE - YOU WILL LOST CONTROL OF YOUR ACCOUNT.
Now, to build the chain, use this snippet:
Output:
Ed25519 => Ed25519 transaction
Example of simplest transaction - from default account to default account
Result(see the structure)
Send
Result
where:
shard - context of transaction
blockID - the block where tx is
order - position of this tx in block
isOk - status to check if tx successfully processed or not
Optional fields:
reason - in case tx failed you can use this reason to understand why
createdContractAddress - only in txs where contract was deployed. It might be WASM or EVM contract
extraDataToReceipt - optional object with extra data (for example - result of contract call)
Check explorer:
If you check this tx in explorer you should see:

Ed25519 => BLS(multisig address) transaction
A transfer transaction to a multisig address is literally 1 step more complicated. So, when you are going to send something to a multisig address, depending on whether the recipient's account already exists on the network, you need to specify an additional rev_t field that indicates the reverse threshold.
What is reverse threshold?
Imagine that you and your 3 friends are going to manage some resources together, whether it be native KLY coins or some tokens. For this, it is obviously worth using a multisig address.
Let's assume that you agree that the decision is considered accepted if the voting threshold of 3/4 is reached (3 out of 4 friends agree to spend coins or call some kind of smart contract). So, if the threshold is 3/4, then the reverse threshold in this case will be 1 (because 4-3 = 1).
Here are some examples for other cases:
Reverse threshold = 3 for a situation where you need 7/10 agreements
Reverse threshold = 2 for a situation where you need 3/5 agreements
And so on
The reverse threshold was introduced in response to the ability of BLS signatures and public keys to aggregation. Since the situation is often such that
where:
N is the number of sides of the multi-signature
T is the threshold
and when checking the signature we need to know whether the threshold has been reached, then we need to do this:
Present the consenting parties as an aggregated public key and an aggregated BLS signature
In a separate array, present the public BLS keys of those who do not agree with the decision (or could not vote for some reason)
Going back to the 4 friends example, if we have a threshold of 3/4, then it makes more sense to aggregate 3 signatures and 3 public keys into 1 and separately present 1 public key of the one who disagrees than to provide 3 separate keys and signatures from 4.
Let's look at a specific example
You and 3 your friends generate multisig pairs(public + private key) locally. Let's do it with Web1337:
Output:
Now, you need to aggregate your 4 public keys to get the root public key and receive payments for collective usage.
Output:
Now you can accept payments for this address.
From sender's point of view
When you need to send something to multisig account you need to set the reverse threshold if account still not exists or use rev_t property of already existed account
So, if account 0xb89c4bf0b9dab0224201d06d46ed6cb49b94f34f8dc8feb0d7bad77caab5b41fc16531dce9ba2cba5784359d2b701cc4 still not in state - use this template:
Result:
After this transaction, new account will be added to state:
As you see, new multisig account is created. Also, the rev_t is set to 1 what means that the number of dissenting sides can be 1.
In case account was already in state - get the rev_t from information about account:
And then, use the value of rev_t to build the transaction as above
Ed25519 => TBLS(thresholdsig address) transaction
In this transaction you send something to TBLS root public key which controled by group of N members
Ed25519 => PostQuantum(Dilithium/BLISS) transaction
In this transaction you send your assets to the BLAKE3 hash of public key of some post-quantum signatures schemes like DIlithium or BLISS (we support 2 algorithms)
NOW ATTENTION:
In case you fund a NEW post-quantum account you need to add the post-quantum pubkey of recipient to payload
By default, you recipient have locally keypair like this:
Case 1: His account already in state and has balance
In case recipient account already exists, just ask him for address.
In this case your payload of transaction will look like this:
Case 2: Recipient account will be new and didn't exists before tx
So, if you fund new account the payload of your transaction should be:
See
⚛️Post-quantum transactionsLast updated
Was this helpful?