🔐Default Ed25519 transactions

Solana compatible accounts

Create and send default transaction

Here we propose the example of simple transaction from default account(ed25519) to any other account

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.

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:

Picture from local explorer

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

T>TNT > T-N

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

We'll talk more about TBLS in the next parts. Just now you need to know the 48-byte root public key

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:

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:

In case PQC account of recipient do not exist - include additional field pqcPub to payload to let the network to create pubkey:address pair in state

See

⚛️Post-quantum transactions

We'll talk about PQC accounts later. Just now, as a sender you just need to know only the address of recipient - it's 256-bit BLAKE3 hash of public key

Last updated

Was this helpful?