Intro

This will be a short article where we would like to introduce you to the naming system on KLY. Instead of calling it domains — like other networks (such as Ethereum, Near, Solana) we decided to give a more general term — alias.

In this article, we will briefly introduce you to the flexible naming mechanism that is planned to be introduced into the KLY ecosystem.

Let’s begin!

Domain / Subdomain / Handle in social networks = KLY Alias

Unlike other projects that simply replace your address with something similar:

• vitalik.eth
• blackdragon.near
• anatoly.sol

We took a different route. The purpose of aliases was to provide an enhanced ability for developers to use friendly names instead of complex EOA addresses and smart contracts.

Point 0 (extra point) — aliases for user accounts and smart contracts

Blockchains often feature 2 types of entities — user accounts(EOA — externally owned accounts) and smart contracts.

Just for reference, we will allow you to change names for both smart contracts and users

Eg:

• Stablecoins like USDT can confirm the contract address in KLY and receive the alias “Tether”
• A famous person can verify own KLY address and receive the alias “FamousGuy”

Point 1 — bring your domains from Web2 to KLY

We will allow you to link your blogs and organizational websites to addresses and smart contracts. Where can this be useful? Here are a couple of use cases:

1. Accept donations on your blogs to your own address
2. Show business partners your financial transactions in KLY by simply passing them the name of your organization instead of the smart contract address

Point 2 — bring your domains from Web3 to KLY

Yes, you saw everything correctly))) If you already own a domain in another blockchain, simply confirm your ownership and receive it in KLY. It’s simple!!!

Point 3 — create subdomains

For Web2 / Web3 domains it will be possible to create subdomains like real DNS domains, Active Director and so on.

This can be useful if you need a hierarchy. For example, separate separate divisions of your organization, create usernames for your team (say member1.team.kly / member2.team.kly).

More examples:

1. Root organization domain: organization.org
2. Departments: programmers.orgnanization.org, designers.organization.org and testers.organization.org
3. Separate users: tony.testers.organization.org, john.designers.organization.org

This will also be useful for various analytical tools and similar projects (for example Arkham)

Point 4 — bring your handles from social networks for aliases on KLY

Bind your Discord, Twitter, TikTok, Telegram usernames to accounts / smart contracts on KLY 😏

Point 5 — programmable alias logic

Here we are talking about the fact that the network will receive aliases through a smart contract in which you can write the logic:

1) Rotation of aliases
2) Generation of new subdomains

… and much more!

Point 6 — native .kly domain

Of course, we will not ignore the creation of our own .kly domain, which will support the same functionality that was described in the previous paragraphs. We will talk about this in more detail in future articles.

Point 7 — alias market

It’s too early to talk about this, but we believe that the variety of aliases, as well as the set of technologies that stand behind them, will create a whole market for the exchange and purchase/sale of aliases. A separate standard (like ERC) will need to be created for them to work properly within XVM.

Point 8 — future improvements

Multiple aliases per address, custom domains, emojii and much more 🤫

Usage

To see how to use an alias in KLY transactions, check out this tutorial in our documentation

Using KLY Aliases in transactions | KLYNTAR Docs

Summary

One day the following transactions will be possible!

This was just an introductory article to KLY Aliases. Here we have revealed in more detail the details, possibilities and briefly touched upon the future. We hope to see active use of aliases in various applications, wallets, SDKs, and so on.

We’ll talk about technical details in later stages. There we will touch on the architecture of interaction between smart contracts for resolving aliases, for controlling them, and so on.

Stay in touch to always be up to date with news!

Links

• https://docs.klyntar.org/web1337/advance-web1337-usage/thundercloud/using-kly-aliases-in-transactions
• https://twitter.com/KLYN74R
• https://github.com/KLYN74R
• https://discord.gg/f7e7fCp97r

Intro

Hello dear readers of our blog — researchers, users and everyone interested in Web3.

We continue our series of articles and this time the article is again devoted to virtual machines. We will talk about an improvement called storage abstraction.

We will discuss what it is, why we need it and much more. Enjoy reading!

What is storage abstraction?

Storage abstraction is a new concept in Web3 to improve the decentralized storage of account and smart contract data on the blockchain

The storage abstraction is derived from the account abstraction 2.0, which we talked about in the last article of the series.

This new concept focuses on several points. We will talk about them today:

1. XVM storage architecture
2. Low level control of storage
3. Flexible payment schemes for storage-by-subscription
4. Blobs control from VM and access to KLY Storage

XVM storage architecture

As you know, KLYNTAR has XVM — a Frankenstein’s monster that includes EVM and WASM — two dominant virtual machines in the crypto industry.

When working with storage, we needed to consider several factors:

1. EVM has its own storage structure
2. WASM allows us to manage data more flexibly because it receives data from the main environment where it is stored (for example, JavaScript, Golang, Rust environment)

In KLYNTAR, within the framework of storage abstraction, it is possible to perform all types of operations on data (RWX — read, write, execute) from any of the virtual machines. For example, you can:

1. Read data of EVM contract from WASM and vice versa
2. Change data of smart contracts and simple EOA accounts in EVM from WASM VM and vice versa
3. Pay for the usage of storage by EVM smart contract, for example, with stablecoins, the contract of which is deployed in WASM. Or vice versa — pay for the storage of a smart contract in WASM, using EVM contract of WBTC, Tether or another asset. More on this later.

Low level control of storage

Low-level data management can be useful in the following areas:

1. Pre-deployment of the state of the smart contract — instead of bringing the smart contract to the desired state by wasting gas, simply take and send the initial desired state along with the bytecode during deployment
2. Manual storage modification — XVM will allow you to manually change the state of the smart contract storage. This can be much more efficient than running complex logic
3. Upgradeable smart contracts — change the code of your smart contracts without complex low-level games, proxy contracts, and so on. We will talk about it in the next articles

Storage by subscription model

To put it simply, this model is designed to allow smart contracts to pay a small amount for using global decentralized storage. This stimulates the economic interest of validators, and also prevents unnecessary and old smart contracts from being stored on the network.

As part of the storage abstraction, we offer these flexible enhancements to the subscription storage model:

Find out details about your storage consumption

Thanks to the API, you can find out exactly who is occupying/consuming the largest share of your contract storage. This will be useful for blockchain explorers, as well as for programmable payment(more on that in next point):

Program custom payment schemes for your contract storage

This is a very useful feature that will allow you to independently determine how exactly the network will charge you for the part of the global storage you use. Here are some use cases possible thanks to it:

1. For smart contract A, payment for storage is withdrawn from the account of another contract B

2. Each user of your smart contract pays own share independently (see previous paragraph)

3. Part of your contract storage will be paid for with native KLY coins, and the other part — for example, with stablecoins or by liquidating a frozen NFT

4. Separate payment for mappings, logs, custom payment policies for smart contracts of different levels. For example, free storage for DEX or some useful marketplaces that already bring validators enough profit in the form of fees

Blobs control from XVM and access to KLY Storage

We’re finally moving on to something BIG.

As you know, decentralized networks (other crypto projects) usually suffer from the fact that storing large data on the blockchain is impossible or very expensive.

In addition, such data is often difficult to manage due to limitations within virtual machines.

Thanks to the storage abstraction, you can manage large data that will be stored off-chain using the KLY Storage service. This is somewhat reminiscent of Filecoin’s FVM implementation

Here are some use cases:

1. You can tell the network to download some large piece of data and store it on X nodes in the form of Y copies for Z days

2. RW(read/write) actions with big data directly from smart-contracts

Summing up

We at the KLY Foundation try to create new and useful innovations for the crypto industry. We hope that storage abstraction will be a frequently used functionality among DApps developers, and we also hope that ordinary users will appreciate it.

We are happy to work for you! Continue to follow us on Twitter, read our blog on Medium, discover new developments on GitHub, and subscribe to our other resources. See you soon!

Links

• https://docs.klyntar.org/web1337/advance-web1337-usage/abstraction/storage-abstraction
• https://docs.klyntar.org/web1337/advance-web1337-usage/abstraction/account-abstraction
• https://twitter.com/KLYN74R
• https://github.com/KLYN74R
• https://discord.gg/f7e7fCp97r

Preface

Hello everybody 👋👋👋

After a break, we are finally bringing our blog back to life!

A lot of work has been done recently, the project has acquired many improvements and we are happy to tell you about this in a series of articles that will now be published on a regular basis.

Enjoy reading 😄

Intro

While working on the project, we wanted to implement and add to it all those features that we ourselves lacked when interacting with other existing projects — Ethereum, Solana, TON, Avalanche, Near and others.

In an effort to improve the user experience when interacting with our network, as well as to open up new opportunities for DApps (DEXes, landing protocols, NFT marketplaces, etc.), we decided to radically change the classic course of transactions in the cryptocurrency network.

Further in the article you will learn about account abstraction 2.0 — what it is, why it was created and what new opportunities it offers.

Origins

Co-authored by Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Alex Forshtat (@forshtat), Kristof Gazso (@kristofgazso), Tjaden Hess (@tjade273), ERC-4337 introduces account abstraction which, in short, allows transactions with some improvements, for example:

• Fees in ERC-20
• Custom signature schemes
• Sponsored transactions

And some other improvements. Find out more in the Ethereum EIPs tracker.

Let’s finally figure out what prompted us to create v2 account abstraction on KLY.

Nativeness

Classic EIP was designed with the emphasis that the forkless path would be chosen. That is, backward compatibility will be maintained and no changes will be made to the virtual machine level.

It is this problem that gives rise to the complexity of EIP-4337. Just take a look at the diagram:

With this architecture, 2 actors are added to the system — a bundler and a paymaster.

This makes things more difficult for you as a user and for smart contract developers.

In addition, you need to pay additional fees — for example, for using tokens as a fee when you do not have the network’s native coins. The bundler also receives part of the fees for the performance of its services.

But don’t you want to simplify everything?)

In our network, everything comes down to a single smart contract that is responsible for all the logic of the transaction. Besides:

No bundlers, no extra fees, no need in native currency at all and complicated logic — just straightforward logic, full decentralization and control

High level explanation

To make everything as simple as possible, we introduce only 1 step between you and the transaction — this is a paymaster smart contract that you bind to your account and the logic of which will be called when the network tries to get a fee from you

1. As you can see, the entire transaction life cycle logic is programmed in one contract
2. When a user (Account1 in this case) sends a transaction, the network takes from the binding table the address of the contract that will pay for gas (ContractA in this case) and checks how many funds can be withdrawn in order to limit the gas limit for this transaction
3. After completing a transaction (be it a regular transaction or calling a contract), the logic is launched that will pay the network a fee

In this smart contract it will be possible to describe a variety of logic, for example:

1. Program the logic for distributing fees — send the full fee to the block creator, send part to charities, distribute rewards between several validators and much more!
2. Program the logic for paying for different parts of the transaction in different currencies(tokens). For example, like this in the diagram

In technical terms, the paymaster’s smart contract will be able to receive various transaction details from the network via the API — its call stack, raw transaction object, access to logs, and so on.

Based on this data, you will be able, for example, to pay part of the commissions in stablecoins, part — in wrapped tokens (or NFTs in general), and part of the gas will be forgiven to you thanks to the system of subscriptions and boosts (more on this later)

No need in native currency — at all

Whether in EIP-4337 or in RIP-7560, the problem remains that in any case the actors (bundler and paymaster in EIP-4337 and paymaster in RIP-7560) you need to have the native currency of the network, which will be paid to validators as a commission.

Account Abstraction 2.0 proposed by the KLY project removes the need for a native currency altogether. That is, not only you no longer need to own the native currency of the network, but also the paymaster.

Instead, validators will be paid a commission directly into the account — in stablecoins, wrapped assets, ERC-X tokens, and so on.

We consider this innovation extremely important and are glad that you will be able to put it into practice)

The first L1 XVM with account abstraction support

Account abstraction support has started to gain popularity in EVM networks, but the situation is a little worse with WASM-compatible virtual machines.

We are pleased to announce that KLYNTAR will become:

The first XVM with improved account abstraction support!

Here is the high level architecture of XVM

The account abstraction 2.0 in KLY will extend to both virtual machines and even have support for bi-directional cross-VMs calls. This will allow you, for example, to pay in smart contract tokens on EVM (for example USDT) when working with smart contracts inside WASM.

Summary

It’s time for a conclusion.

Working on our project, we want to give you the highest quality user experience, as well as make innovations for the crypto industry.

We hope that you, as a user and/or developer, can learn about the benefits of our features from your own experience.

We will be releasing many articles about the project and the ecosystem — so stay tuned and see you soon! 😊😊😊

Links

• https://eips.ethereum.org/EIPS/eip-4337
• https://docs.klyntar.org/web1337/advance-web1337-usage/abstraction/account-abstraction
• https://twitter.com/KLYN74R
• https://github.com/KLYN74R

Intro

While working on the KLY network, we had a dream like the sheikhs from Dubai — we should have everything that is the fastest, the best, the most reliable and the largest. We did not want to create a network that, having its own features and innovations, would have a positive impact on the crypto industry — on its present and future.

That is why, in this article we would like to introduce you to one of the pillars of the KLYNTAR project — multistaking. This mechanism is innovative for L1 chains (or L0, given the fact that there are other blockchains in the KLY ecosystem). We will tell you what this mechanism is and what impact it will have on the KLY project and the industry in particular.

Let’s get started!

What is multistaking?

Multistaking — next generation of staking mechanisms in the crypto industry

In recent years, when the vector of the blockchain security model has changed towards PoS & BFT consensuses, staking has become a standard mechanism for guaranteeing the integrity of validators.

Its principle is simple:

1. The validator promises to be honest and play by the rules of consensus — not to create forks, to be constantly (or almost constantly) online, and so on.
2. The validator benefits from this because he wants to receive commissions for network transactions and/or a reward for generating a block (each blockchain has its own way)
3. The network cannot simply trust the validator and asks to freeze some of the network’s coins as a guarantee of the validator’s honesty. Thus, the network insures itself by not allowing the validator to disrupt the network because he cannot sell frozen coins

Since KLY is also built on the modified BFT Tachyon consensus, we follow a similar principle.

However, not all so simple 😏

The basic idea of multistaking is that we don’t care what you risk, just stay honest and follow the network rules

Currently, networks that support staking face the following problems:

1. Lack of staking power makes network insecure and centralized
2. Potential stakers and ordinary hodlers don’t want to sell their bitcoins, ethers or other tokens to become staker in a new network because they are afraid of losing investments because of volatility
3. Stakers(delegate coins to validators) are afraid to provide their coins to unknown pools. As a result, in most cryptocurrencies you know, the most influential pools are the same representatives — staking services and CEXes. Example — Everstake, Binance, Coinbase, etc.
4. New crypto projects that appear should use their own small groups of validators for security. As a result, we get many semi-secure and semi-centralized blockchains

Let’s see how multistaking solves these problems

The highest possible security in the history of the industry — stake everything you have

Multistaking expands the boundaries of staking to the maximum of the crypto industry

With multistaking you can provide your bitcoins, ethers, NFTs, stablecoins and so on to become a staker 🔥🔥🔥

Now, not only the network’s native coins will protect it, but also any other resource that has value. This approach has 2 important advantages:

1. Staking power grows up to endless values👀. Now network emission is not a limit for staking
2. Protect your stakes from volatility 💸 (because no need to risk and sell your BTC to become a staker on KLY)

We plan to support both tokens on our network and tokens on other trusted networks. For example, your stake could be:

1. USDT from smart contract in KLY-EVM
2. Memecoin from the Solana network
3. Stablecoin from the Ethereum network

And so on😼

Unobtanium — a unified staking points on KLY

In order to unify staking resources, an additional resource was introduced into the network protocol, which we called unobtanium — by analogy with the fantastic mineral from the Avatar movie. In the following text and in the code you will see its names as unobtanium or UNO(shortly).

Unobtanium is credited to your account in accordance with your stake. Oracles and a system smart contract for minting unobtanium will be responsible for this.

For example, here is a diagram that will clarify the situation:

You can use the points you receive to stake validators and you will receive a percentage of their income.

Risk-free staking — start to stake in a trustless way

The main problem with many staking-based networks is the fact that you must trust the pool you are staking on. Ultimately, you don’t want to lose your bet.

Also, you have to freeze your coins for a while. Although liquid staking protocols exist, they do not in any way impact the security of the underlying network.

Our task is to do so:

1. It was possible to bet safely even on small (less popular) pools. They usually offer a better return percentage than larger, well-known pools
2. The resource that will be used for staking must be difficult to obtain, but at the same time be untradable so that in the event of a bet on a malicious pool and slashing, you are not afraid of losing your resources

We present risk-free staking — a system where you can use various resources for staking without the risk of slashing.

Such resources could be:

1. UTXO age of bitcoins — it is very time-consuming to mine 1 BTC with an age of more than 600,000 blocks (for example)
2. The fact that you are a validator in other blockchains — given the fact that they are secure, it can be argued that 67% of them are honest and can be allowed to be a validator on KLY. WE NEED MAXIMUM DECENTRALIZATION
3. The number of blocks you have mined in mining networks (BTC, LTC, etc)
4. The beauty of the block hash in the Solana blockchain(e.g. vanity prefixes)

Example

Let us demonstrate a step-by-step example of how this can work using Bitcoin as an example:

In this example, the user Kappa(famous meme) wants to receive staking points on the KLY blockchain. He has 0.05 bitcoins that are more than 10 000 blocks old. Bitcoins are held in 3 UTXOs and are used as transaction inputs.

1. In the first step, Kappa prepares its UTXOs — for example through a wallet application or through software SDKs
2. Next, Kappa creates a transaction where it indicates 2 outputs — sending bitcoins to itself and OP_RETURN output where it indicates its address in the KLY network
3. Then the transaction is added to the Bitcoin network and its hash is equal to feed1337…
4. Now Kappa goes to KLYNTAR and creates a transaction calling the system smart contract for minting unobtanium. The KLY network checks that sufficiently old inputs have actually been spent (with an age of more than 10 000 blocks) and adds the required amount of UNO that can be used for staking

It is important to note that multistaking is such a flexible system that for each resource at different times you can assign your own conditions — the age of UTXOs for bitcoins, the rarity of the hash of a block created in Ethereum, and so on.

Let’s clarify a couple of points why this is a win-win strategy:

1. Hodlers of different assets get an additional opportunity to earn money
2. The KLY network increases decentralization (Nakamoto coefficient) and maximum level of security
3. We can afford such a risk-free mechanism for stakers because the number of honest players (miners, validators and ordinary users) in other networks is significantly higher than the number of attackers. In fact, to have a serious impact on the network, an attacker now needs to control more than 33% of all resources of the entire blockchain industry. And this is hundreds of billions of dollars

Shared Security Mechanism

One of the products of our ecosystem will be KLY Blockchains — the ability to launch your own blockchain in the KLYNTAR ecosystem like Cosmos & Polkadot.

Working together we get:

1. Possibility of creating a common security layer
2. Data exchange between chains
3. Other types of cooperation (serverless blockchains, etc.)

Let’s stop at point 1

By launching your blockchain in our ecosystem, you can use all (or at least part of it) liquidity in the form of KLY & UNO + resources from other KLY Blockchains to create your own set of validators.

We hope that such a mechanism will have a positive impact on the fault tolerance and security of new blockchains. We will talk about KLY Blockchains in future articles.

Summary

Damn, we are so glad that we are gradually revealing our technologies and developments and introducing more and more people to them🔥 With each article, you are more and more immersed in the whole development stack.

In general, the multistaking scheme looks like this:

We can’t wait to share with you other developments and innovations of our project. Stay in touch to keep up to date with the news!

Links

• https://docs.klyntar.org
• https://twitter.com/KLYN74R
• https://github.com/KLYN74R
• https://discord.gg/f7e7fCp97r
• https://docs.klyntar.org/deep-dive-into-kly/run-kly-validator

Intro

Hello folks👋 After a short break, we’re again here. Working on plan for articles that we’re going to publish, we’ve decided to split it into series.

This is the first article related to cryptography on KLYNTAR. The set of articles under such title will be called Cryptoland, so if you see this label — you can be sure that something interesting is waiting for you.

To warm up, we want to tell you about type of addresses on KLYNTAR, because that’s what you as users have to deal with very often to interact with KLY ecosystem. Let’s get it started!

By the way, today we present just a short intro. We’ll discuss more in details in the next parts of Cryptoland set of articles

Ed25519 default address(Solana compatible)

Let’s start with the simplest. KLYNTAR use Ed25519 as the most default key pair that you can use as account. Key sizes(both private and public) are 32 bytes and the signature is 64 bytes long. Definitely we need to encode raw bytes — that’s why we use Base58 encoding for public keys(to be URI friendly) and Base64 for signature.

The typical key pair after generation looks like this

{
  mnemonic: "cousin long sentence know chest illegal strong whip wine good rather smooth",
  bip44Path: "m/44'/7331'/0'/0'",
  pub: "AnWUvHhFiuwSarF8zw4fwC4tgBt8gm22w4f3CBJCDcVD",
  prv: "MC4CAQAwBQYDK2VwBCIEIIR2ZwvbcYayIxis8Rc45v5BHOlLaAyrIqVFjuNZPVLA"
}

And the general scheme of creating account looks like this

The public key in Base58 is your KLYNTAR address that can be used in KLY ecosystem. You can generate it even using OpenSSL.

openssl genpkey -algorithm ed25519 -outform DER -out ed25519_private

cat ed25519_private | base64

//...something like MC4CAQAwBQYDK2VwBCIEIDNfdnUlKdo4fYCG+NzoEQRyanCphYKZUA9XX8uFI7nV

And public key

openssl pkey -outform DER -pubout -in ed25519_private -inform DER -out ed25519_pub

cat ed25519_pub | base64

//...MCowBQYDK2VwAyEA4PbMaYPMC+iTYtEfcNJmdoa4o8L0+yvQB2JEHLzRfi8=

It remains only to convert the public key to byte form, remove the first 12 bytes and convert to Base58.

Also, as you see, KLYNTAR supports BIP-39 and BIP-44, and we even have a 7331(reversed 1337) as a BIP-44 identifier for hierarchical deterministic chains of accounts generation.

Added KLYNTAR by VladChernenko · Pull Request #1388 · satoshilabs/slips

By the way, KLYNTAR addresses are compatible with Solana (given the fact that their default addresses are just a public key in Base58). Moreover, the commit transaction of our files with ideas related to KLYNTAR on the Solana mainnet (with a program Memo call) was made by the KLYNTAR keys

Explorer | Solana

More details here:

Default Ed25519 transactions | KLYNTAR Docs

BLS multisig accounts

Today’s blockchains definitely should allow users to use advanced cryptographic logic by multiple sides for common solutions. Multisignatures is a must-have solution for different use cases like:

1. Decentralized bridges
2. Minters logic(add tokens, mint some new NFTs,etc.)
3. Oracles workflow(prices feeds, real world data)

That’s why, we’ve decided to add multisig accounts support. You can use it in contracts(both for WASM & EVM) or as a standalone address.

We use it for signatures & pubkeys aggregation and other type of interaction like voting, commits to hostchains and so on.

This type of accounts have the following parameters:

• 48-bytes Base58 ecoded public key(used as address)
• 32-bytes hexadecimal private key
• 96-bytes Base64 encoded signature

For instance, this is how account looks in a raw form:

{
   "privateKey":"caad28a7da57fb28879bfdd886714629e4152553a28540caed6f51531f5af61a",
   "pubKey":"7QMxLg6GJwQYjc8B2WBEvaQq3TfeBhgBqHGneFu43oLfwhovrPGykbkUGe94FacSuG"
 }

You can find more examples of using and generating BLS in the KLY documentation. Get started now!

BLS multisig transactions | KLYNTAR Docs

TBLS for threshold signature accounts

Multisignatures is good for multiple of cases, but there is a problem. Imagine, that you want to set 18/34 threshold using default BLS key pairs. In the worst case, if 16 of 34 refuse to sign something(for example some DAO solution), you will need to publish the following data as a proof of solution:

1. 1 aggregated 96-bytes signature
2. 1 aggregated 48-bytes public key(signers key)
3. 16 other 48-bytes public keys in a pure form to show that 1 aggregated pubkey contains 18 aggregated pubkeys inside and that together all this 34 pubkeys equal to 1 root pubkey that was defined as authority.

Sounds not good😔…but there is a solution — TBLS accounts. Long story short, threshold account allows your group to hide “threshold details” from network and publish single signature as a proof of group solution without revealing any extra data(sounds like zero knowledge mechanisms).

With TBLS you can set different threshold like 25/36, 101/200, etc.

We have added a very detailed and step-by-step description of using TBLS in our documentation

TBLS thresholdsig transactions | KLYNTAR Docs

Dilithium / BLISS post-quantum accounts🔥🔥🔥

Yes…it’s here. KLYNTAR was designed as a sigma of crypto project that’s why it’s impossible to imagine KLY without so advanced cryptography.

Honestly, we spent enough time to find reliable implementation of algorithms and decided to add two types of supported post-quantum accounts.

At the initial stages, we decided to use Dilithium and BLISS signatures. Among other algorithms, their ratio of security and sizes of public keys + signatures seemed to be optimal. They show good speed and can take part in various events on KLYNTAR. We recommend using them as an advanced security address. For example, you can store large amounts on them and use them infrequently or even through a cold wallet.

They added to KLYNTAR core as addons and already available to use(generate pairs/sign data/verify signatures) via Web1337.

KlyntarCore/KLY_Addons at main · KLYN74R/KlyntarCore

The address that can be used is a BLAKE3 hash of public key that automatically generated with the pair. For example, this is how it looks

let postQuantumDilithium={

    pub: 'bfafb8ac70403cb603342a90b0f62673a2bbd2cd237148d47620794135abeeba56b72ce5d2e6df9b96d11b2335f23712735eaeeeaf25c1f1d5709dccff4387146e8c7ed52ae6982b0ca5a6e921c4f61e2c527e2d9da3d7a842372e34290aea51781a1f561f0daf49e6a0a1067524099a4741c7f64a25a55d02a2971b31ab27f6baae0c66f7bfc7619d03ff3771b029378c5e79b725b6ce9c39a0cf4c8708993c19b65fd3492a96076b01fa2f89c5bc49c142db67480460adcf9f628486e6cac6af8340bd96345bb9e8ef41905e5f5082428393ffa8ae978830ad3d96b5f705c45f0640d87fecee7a43e6c0c493833c72d24d2108dad6e20b2ad36a38f1790d835238138831fbb93dfd9f11f46cc2e7ebdccd3f76d0c160cdd743969ec5ce8ad26029f85325713e083f9fe8169f235ab2d719c7135b1ab8deec707f0caf1d118fbfe469f65d29fd88fb07a6d4d3adc861df4c8f2708ea0357ccf4b396cd1c0b41aed632527508c2396010de94134d90dc03a30a95e32336ab839c7b3976583891ccda980c9104c8de8dd784ba9c587a93083c4ae4f9d117e025e2cbb3c53b8828e11199f1fed89dca12e521df07eed3e28cab3fe1e1404c5891ee29e95854536cc065e1afd558e7da0adce618fd09953820df5bb959dfe317d5ad7b2882e33c637851956898438c10f3537d907a5f68e6c813f40b2e4ddd25f6d8fe57ac456cfd0477a327dff747ccf469356b0ba1365860b39ca038670a8f4255755c5b8d8925d70a3bca508c0d53c75a9d7863aea0fdc0964fae59c2ecf150620224e49096064bc56689b169f4dab85c964bac05036c6ba0006f300cbc72dd866574e76a35ec239bc94d4b7601baf13da3eb9457714748ab82e80ebfa163618c64926ac06fa6ca83d713ab7b1debd78d115244ad7924175e00d827675f248c5c54b247d425d3fa379fbb9c1b90b1d5e7242132cd3e672891e3eda74651585f4d5038bfe12a8a3b289f15ea42dfe480f1a76290b2e78e7f8668712e144af4eeb9906235285e669f4c85d268ec6dcb73310331dc2550b151b41df6b570d7124f90af0f6ad18b2e296afd30c08eb36e1fe2d58d8ad462482c598a0e17e55c4f101af212356d9cee2aa1fb8342fe26b060e93509e21d895f11f742d4707b74027348b2838a045c51c10dd0c8fe563fd813bb6f99ebaf20182431d927fd6738c8c9731086997b1b9cb2ed628bd931ca996db3572b6ce075e0e78bdfc066790110e5e8e538c11623ceaf66e14aa1757ce052f52b9c9bee54f765b74a48de44cad593d4973bf84f663b594d475fcfc638fef7414d546fb2fdd0785958499ea16fbc7df84646d05b769675f781538319447292f72304a163d1f7155d72fda67907b7af9bee6a0b323c65e4800603f72501027e339691c899b4154d519a3fcb5d33824e06e194fdbcb4e7a390151915b644e55416cfc129ed2a07e30a7adf1a363dfcc3e20731ec2ba18c6115324516de9bea5b1f3b0852aece124648340842b4658484da6f53d5edfb197d081cc96fdfcb350e4152b3eb17853cca40b6d584e81bf133b098962f876054a77faeacc662a935056893c06c876d92392457d4465372a3770911772eedb507e2d54645229c5aa1217dc1bb0a4a6f6e90e46a60d35e790e0283a31f754ede7be16619050abc7abc93ba06965d59c50d2f9e749a2151724369928dee17f4a2ff469a0c449c69c7e94cc1a9a0a74948b19672483cfeaea253bdbb032ff22edd80fe6024e087893f29f7fa3f03b346b7719f4946010d4eb7d42f0a6b37f616b3b54417e507f04e5fffc640eb31ff50a7d227462710c29181d116dcbae010a23b82f865b8e90f8f29096216dbb932ae9df1aa51befacfb730b08bb08907a660a06336ac2bba2026a4133ee471ebe369e2b2d29c2e7b7eae15c827b9b615107f13fd8fe7d74362e15cf9afaa7fa352eaff83db0dc68504c96a5b3999ad1fccd78018f4a6d50745f4c8835fb0adc93dc921953d2ec161f53664ae9a7e73e879469c42b52beb9c2a14ab5e3e12f64f9a80dac4844a887443b0b0d4c290462d0712e9a02d2f216f99f15235a23b4ca6d628e28d3d9c2af79686ae09ca110611577fee4a204c7bab4d23d1da5b29edbee9489b3f3c119e2dfe796b7a758aed1a9280f39b73a5d9b5888e52f4c5c2ed9434fb53940c1878ebaa369bc40a31c8227da7ede0cf3e2f619744bf1ede2adfe2d91256522b66fcd6ac194e13e2c0b069708e0df9b8a3e0b3b02614400b7ba69be77453b7be612ecb6adfde93b64ce01c07f28de175f71b657d53414a7cb1ccdabe770d4f7b3a1f6dee1548f7d8e6491d7054afc434837009c53ebf9762074900b7afeb2bfa172b4e2980aee6089c3e6b776b18fc63866b18f17be22aa8c705f70c4daf428bb408f14deadb5ee26f1e22c29fe6d0923336fab98e866399758d06dbda2558ce14bf2e9d5e5aa70b10096939c17471e8391fb9ff7f013c6fa68150dc6373b50439676a468a0b2effb6eb1c7c2c4a1df38fd6f1c9cee639f7d8fce7b838fa13c3905b366bc0f4d0b9a417d82e42405ea175319b565df822beb8915dada8500aab1436bf632500f2eb72e32fbc2026e89808cf2c91a5c1b98ad767a73d0b3a8d60d24283686d65f2563c5b40d35d1c305760c18715211f955e4ca04dfb35c2c9dbee08c62470ee2db89c06817992ef10eadaff468d21afcff0a480dde314f4976699b48841074e8b2cd259198a9c2a149cd984e0187e77bb3d5d3e229e2b4502f0d6433342c0325d3140a23f2e0c0ee8274ecb2bd35217722beb2fa529f549714a4e1a07170b326edf043958b5a63739395a988a693e25c25e74a64b44c00f750329c55e6647e0c5a2760914ff1cd7add97de4bddccffee21747f9d150baa3abc59de5804309a8d932652b793803b50db3c7811265b87a71e4d6ad9b54809d66b542aed1dacd0a3b1057f196ee7afefb8b59ec09fca0c7b7941dbed1b642b0ab96c0b8fe5b1aa62b63861f220c8b89bc9af95ed52fd0f683ead5b39495163188cca5298d51e91860021919ac2f7af737adb4a03592bd2bc590e1ad064f831a1841ea1f35836885d40192113cf55cbd589df21f5d1716e88eebb79494ca6a3ba908e0b1e098d31a0e30d87ce08d52145995a57ecb51c02d9ab0a516fcb2b288646dbad6eb32579635a841e3c111ed7cbeae065d58cba66c26f1191ca9ae90adc5d6496a41ddf4c22885923fa5a8d0e60c51fd6b2c6300daa0018a12d71351b7cb58f81c3e7bca4d729ab6bbe597b57e0772bac47c5b33235eb2cc4d33aeaabb5dad9cb247aba7aa90be1c3dbce42b7214e1cf99b11da92496213006d528f344e4af2156f385eaba211582a49292daf1721dc834f86dffe908b099c3b65259940daef5649955a3939ceb5de7f6199d0aff23dbe25af939a9d119ba12d16366abcc5c0c07aae531fec8153eff260a4bc81195aa9d7f7478558cd3f89ec23690acb0a5705b31e7ff899a98f129696ef923af9f31185dae1645cc3d680cdc8c3f4160b202089f1102e6c27e5ee949f17efeb5adae1f50c53527876b3e4dd03337aa3688d9fc60d288dde8e4d8c3c74c4fc11c572b07b2a00d1d26e0682fcf868a4ff96db5d1993a4ccab7646fe08ec69d0031',
    prv: 'bfafb8ac70403cb603342a90b0f62673a2bbd2cd237148d47620794135abeeba4968f5030f39cba05052505c6fbee0e4230519f2ad11f2edd7d95d2b53266bf673d735deba83fa286679bc5c8b98baf29e03826e8da7c1fbb2675f2f1b706e2e60360a13a36403034852b688a22406481012888011c9305201a44800028283c001100141c2800049404d58200212498d881060e0a83023c8218bc669e11809a186491212610b2032e3a850c9342c5aa284d1c68988428964444d90060964244022c75103b381e0b48062c82009063153a8240c41020a828500100e6426510aa86da1b86892c24409137220200dd89664e0460512c78c01b0488c206e009061148568d036904b228d0c95241c208d181669db400e11a52888062edb224621125280240ccba669513285a230692425281a27080a101202b74d13c14d8c304064402ac9b8241c17899a209224199252c4694836304c366d98384e23c9495c8405e4046698947104c30122b9304a8229d432901c944d08475052a46924b190da08080bc12504130e11b91018108002c510a4062e628621614600d2c4251a924022043002940d948868db023211c62d8036025406405a048248422ddb1412101782e03860990800c114728a4206c3a06dc4c41010c448d04620940682c1126e0436448c204842c671c930711b834d41a064d2924590a82ddb8601d9340009a96961064c1114606248602385201cc681d490250c452d0a407124c38c119030c1a85021252cd2262c013461a3904dc48225dca4500a256a1229921c2460090951592864148220c0b008243944da048204022e0a012e9bb068141186da340018150251966d1c89206046215b008c12173113b14dda16120a9089d3a010c1822593408c1205125112641b310aa2b871d9108d0033040a0432dac010123102e3042ed2860d834442d9b84cc1120688003263222890a249c2184ed9042da216688c0208e02631c28469c84491dbc491d12891d2448858828cd8485183420cd0048c222269482632823228233321901864209610dc9629d4c84c61283191b408490286d20249012345c2b60d212709d4a2401ba3651a44448bb22c1b04711c020c1a21244010510c418d08030890804551b031234846833804123862ca802c43824512094609214d0915421b866840026c02c788043050cba06080865140c46084308100892488b270d1448d1419901ba4691a048e2244855ab2290ca001ccb40d24c80c22a3488b864c524260d41090e1c829d08091c92628412471ccc201e3160aa2b860e2162cc12020a2c6602336651bc39154044e9434291bb04008b09192082d02a820849044c89401812204c9a40d99c22cc8b805da1068d03065c49251cc02049a200c9ab440e39644c208328ac824da0264419884e4461203b02c1b85251212454bc2904c12081a354e53a2210c314252c66008814c0ab060dc2660d800818b1826c0960c41404ad1486a6182909830420bb28011459143822119268c4a308109452c0b420919c965d2082203c730cc221188263183026803232911c26dccb86118394dd3148a044328a3228e88b26c01957110a92983084ea4a0495326265ba871c1926d89003018c328c9003289382e12196a81b88009496414964d40b80542422a239809514022904612021789239451208331a4b66c8246889a048453c0481b352488942541384593306649084024a660e1083083084a5a94441b2245808809c114305c462d01113193468689188a48b42581086143066920c7308236060846805c120a12b3490a00600999490090451cc0095832520c406250308ad8b81019164108392898b649d3328e0a82008c12721c0681022549423424c0042621b06d94c20410100e0239428b2289d2487102168d02370a64100ae0140c2002241028890491090c43481a224c24c69000c641601432c8049192844598387222880003a20c4496901a3310213200d400208b8008204521512090d9c03091204c0889118b44919848025ba821083260e410052311519b4482e1202d190589519609e19241012648e49045e2966498169211a64d13a2299b4250240461c2a68d82c210a4120903157003204e118169c0221214154409a2500827650c9611040085dcb8248d61b8cda53d8ec94c17f5700f28dda5d9ac7a759521c4cbf53d3201883c1dce095fb230926afdb3fd13f1c0317d8a3d1bae5b8d39ad2d123bbba4aea9618168ba9b42392ed57d1fad85fff388e26897e51c8cb2ceafc405a1e618f339b6ca11db667719c1c6ec811db902dafb94e5eed6644592f390f42f6d741fcdf9b8511432c260f51a7c900ada82f550732ad013606287e860b5d6413dacaf3d0916e9be2afafdbe9a8949d05fece51919bb8b6403d59af1f2435ea102f419d31c63a209d4dda92ecb73b288d855bdb89faaba1f33f7590dee25a2202f04117e721528013c6bb9424b8ed41a655c6e1926b283a7dcc2a3899935fc4cd4cb78bb7b7cb06d7cf21f1c8a86ea0c818ab86a0526ff4e43ddbabdb8507212c79506ad54d6afa195a0f35c391693852c64014b9aa6450805b75982fbfe2321a8eb80a7a415550ce92ee3e9c01496ed9f82cfcd54568e0cfa50280afa927081d36bf19a76b94d24c69ffd7a6e2865c41a3a69d3b76816f450d6d71865d1721076402cefa8c68987e2fba474cbec44a91d5fe375a4ff68a408566b919f315e09a00a678b614b938d82a692e7f26a81319837600091267a088cfc2aeb04563ec6ddf762508cda60893869a54b7a9058f00e68e814bfda071923d89e544474b81acd90a60c16e270104c4efe5e712556ed007b4b6e9ba5ffa8f967094d6b1263aeaa5f827a7c32b993d6d455bcd803b448455297d8dbc66f695df2df49d3fb61f9a1fd0dd8d40004a68143589d83d5757ecd431e96a09ba9a825444fb3eae0d3dc9a60bfbb36def16867a8d2534bf347605dfd3bb192ffa59471e7a58a93bf33ba57f424fefcd00def85c3e1b1323958f1bf1e70999d82bc6cb69ba0b0bb8b98e3c4ca7e49fa0f2c8faeea502f5ee28cff6821f223ab05a599ab5fdcc76f8007a516692e6f4e863a5ca919b9371cac9090959357959e7bac5b2d26d128fb1a21cb3db00e17382d31980967f7781d17f117a7daca7e2bbcfb0a3d4921daaaf43417b7a673e9cf78e1102624bbadd9b62e6e89b2cffe8e1ef746c939323bd23a5f24cf712fe01776d983fd4fa9f22eb773592f8b84ee8be3eb29a41a7a79d31fcdba3a0df399bde9d12760ba010e226937849a9f56469a5c3ed9159e6a1d4341ccf00b3c8dc50b42d8c4c696228d92a6cace380822be55e33fc6c538dc437355b986bc25f4e392a85f8ba8703d75481880ac6674497ed6f7906d046da49b39f7893252dd428e4a60f0104d31e66ef06e7087fcae3d476d71fdb4e28859697d88e980586cf27239da828c01023b4e9f9492f23a68e410fe3c6bafc5eadcac37ed53c1e261592c83630cb9096f3b2148218ec5f994e44afc455ae767318aa83d4f5d4d016753f40a458d00677e42ceda2b9d850feb76f4000cbd5b4543d02bee5999c10c2f042fb6e965d16ea22a7bb07f26ee5bc100cbb2831e7f9ae8c56ba428ebb31cb82c24106be3b3615ba263ed90fbba37b976a58e2a5eb65feb1bfcbf1c463c691c542bc228ea5fa1c1c168ca2ef3acb8fccf801d7551dbe9d00c254f67a0d261d1370aaa81daca2792edc6ff6ee8e64850e2e1f44f99dac0f993a28ecfafe19420e7dddebaedad9ec9bff1beb5f6c8851186d4f0f5232b27e239bc14f3e78b3d982aba60948516666ab4d4d553a3c635fb22635aefac31939b0e69d6231a4fcd767444ae52df00f78216714d4e284081fd66b008d543f23d8a9bb276d1136ea542c0892a1c52121892c2082149003f1ae646948f4e09134da0df87c6aa737a19cba43b2075ebf51e8cd49dae521c4c38a7955f46cb59d3debf9ab8cf3d11e56ebe9a43a2ba69957c57ab86e73deccf7541b5f79bf6f13e1028939353ebec170a8db99226e5364f9b16ba8b5669e2389fc2821049fd975525c84434b02c1252544c7217b828a35bb1c774ef6dc4694df8a965e07568ea43fe7799b278e153b1100ed69353255bfd9ff486966542ba0c6548cdc7eb4f092268024207485840f1b45fc8e6d8366f6affb5a9fd57d6e9ff57ba2e14557e69d7a48c9100e9f6b39e79f2f6ded230f02c09ebca43ffae04271a386aa8cf4f0aa74ea82d028efda3974478869ed59f620ae7f0ee8355a52b2544962991b26f4177968125d101e5eeb52d38cd2249659c9bf7886ee455dfb77b58b1bca3f54c6aff17b9de3901609fa2d33bfc634abc96411a8b1807b6d42d4b6313cecc8f2ca71696ebbfc8e03c6a658c71c250e6cf609de1ca12a20e3a503667b9ba4ec664df03fdf9f9e040d671167eeece6b9c455025114760e861c8e6d739a089309d3677c6d1448ec9cf5250dcd25e8a590597b29e131ce6167e627e629224f8ec8ec84ae7282c348a7b7c716ee364766ab885b65d8529a849112dedc580bb52a51cb1107f3b59e70b1d47c121b3c5f9b26f2e4d10a0450b7dce43f5ecb0be5b91cff412111195d8215bf21ea413c22d9f007f9988d89153e17210c35afd801d0e45af8f6f6c9117c66ced6f0758d128bf13b51a73d86675f80fd65d97cb129cfe7ce4c5c1c9c5f47fd99b3e4c001aedc3837d39d94dbfea5f350a2747ac5d0b0958d45425d9c5260f0ee26a59f2f4b3d498f287229819b87cf76aa4f763459dd8fea899d3dea36f0c89072a65d4f9b7aaf48a6c1d3035d6a46d27a581ab44413608ca56e4c22ba79e0acecf5d4b0ffd055880012b9d0cf21881dffb23246369e3776efa20b06ea7d76f16297714da06d49cbfd136b4f4bc742e5b1d4fbe78d54a63855a75eb353d6412542194f015f9a88cfb83b681207048e47789846e7dda1eff957162f969b3f1a348ec7c6ea9518759618f9ccd6a52e4acacc4c0ab921c21f1ba1ded108bc7462a24938d113d345743f746e253bb24512840c80c0117541ea0064cee4eb4836ca35fa82ce1a06f970f73626d4a0b9ca017e146e3f658d913d455d3f726741dc8e4ef78e820c79a5e0dba7350d9f238c3f232449e5b4563a75f9f23a7352f953ff40a3f530bb09244436df5bf147ff3be40356eb7b366b0d1d15fa04471da896bae32e0f14c0b92632918f56fd91fb65d3d2752cf9944370b0a5dd6f9060e0da4984ea7c6b9869a456d3d7b9293be6b2c58be858ea7498f4976dc5c3bf699e0b7df8dbf249f846cff0cedb6b13754707473f7932511ba84b7ddc795aba3010bb25e46ec2cecb97048cece0b0231f7e3bedf447a06a8104fd89bd78fb2323aa031b14ec161dd32ac1b0383a82016d50fdf50fafab5bc03370fc38cde7cf62b7a3bc928fe007869e6934383b87a2769b01657ca311fe7e9b0f7e2331ebe2bd0f71148830ce01af8c9d64edba289bee7c2c7041ebc7862ca05510d70753cb04e78e855cb0470f75cdeb8043dfa2df584a1e35ca0cf9a64dc866240754a20f7a5e7973436e1bb71bbcc1980f94193585c31a97be54402d18271314884c9d59a7354a87675fb20d9466493087ae75e9fc8ce781e9924f38baf85ced237345c5e4b7e4d0b6111f71d76b3d433e244642d681615856759dcc59fc7d5316150d0c89b46d9e7c5391eaa7e1944748a964680d84c217b62118808c680bfcdf8f824be1e14403df26cd486c16efe5a1589e2d401684619273134ae9a078fde634f2f199ef48f538464d3c187c9a2f304afaab767c997edc6dd29d5419770b50918c514ec07d81e42972006f613c92aad27e810dc686a09f0cedd9d01c399a03bbd0233a14baa9ba09c1afd9c20f8fe2ee383d4eae4c29cda584ef3406da3eedd35ce47ffbd911a466ac5c0760bf2912474214451d4c7364d6ff815321d03dcda4c1a0769bf226610a6821c459df9ebd02f0dbbe58495026d8ad41a4d6ddd63ca99d00f109b65bd0f6fe5e14e3dfdb1ec7dcd58be4dc26d1b9cb93c34bf5704ec566a804bb9cd0ee272df03277f4abe73915ce3d989c547e848d3a5476f7caaea120c62812a3fca6d17a96d82e87d27f201895f2e909ed3e3bc7ade19b1c7eb7532a4fa692e2fdd682f2c290f0b933e5982b652d3ec5ad52b43df8e4220c69977da7636cac5339e3377e4441ab61c8ebb17934a1f83ca0a2ef9c6be2bfc6fbdb277dac9580e8a2baad5406caf2dbea55042cd015b6df0f62ca26dd503bbc35b14df5b8f7c83131800370be8c361cbaa5b85c60c20e944f6564a4bca56bae600eb794f67f266d9059279aa168f24c5150eea6b16182b699506441959f37e0e8107c6bc7b9566e00c2c8456efc77a3f410113b0688cdcecb073023c9f08251a486a962cbb4803f765920e0c997598acb85f8b78d66b66b2bf78ff7cdee1294c0d81f459b0738b6ada2310e1c781353154db959ee8ad90ad0c87cba69ee8155c45036d9d2f5561f605d935b70629332c9437b12858cafabede9b6a2f55949177959ecd1d021c9b552074a467d3995d6b7f38e1028d008ed6d4bbc2300c0dc317b941b3093d5267f364de944dda55c9ec030035d977fd59f2678b581ab2a36e977095cf381520380e1940e09739ce8cca147021163c15467d0dc5d8321be33defe0dbf5f0e28bf694c4570e27e3d21a714a3affd484bd4f2670e222b37885d9d16fcf983885efb855cb73d28ab2b1011c3a507ebfb4d1b7139b06378a8a8fbc2c7083917e56de2aef7f2b34c88af92948fa54a3d46e2eb6ba895cbb3e1019fcba4a6cb066a870103a65105af8f8317ba61f1d5d42',
    address: 'f5091405e28455880fc4191cbda9f1e57f72399e732222d4639294b66d3a5076'

}


let postQuantumBliss={

    pub: '001b4609d500e31a0a188911900aac07fb06f91566038104e90c01031707d6154701701a15046d07f5089f0c730c8515e712c90b5a130d10081bca0ab40c8f0027101501870ccb17041d691bac0c30162d11ff0566198710f308cd08b30be804261a040c530cb8042e16841623069200b9175410a5016a171e1ceb10f813261bae0acc06be176214471d7013530d92180a0dbd15c800fd09f700ed0a8616141a14095b08a71c3317031d78106602ef1c1f1a53097016df192905b50ad40b5c1d1c027e026b0ecb115417ae1b6f1c1101c60d3f1c12016010a309f8183411840d7d12d414071a5b10d1162111f712951b36066209500e1d137d1dbf055417e6075c0ce307460ff9040715b51d0000cc11cf1bd1194c0a2d19e901191c5306040c8002be0d19024f10b31b19152912fe06900de21b2e10110ab111f80b6403ac1b8505221bac09830e3501a1175705c7138e1db6035c09871c4c121706b70b560ac70c001d2305b0107117ef02c1178a13f010bb193004ca02bc035e036f109419770a2017f11dd00cb3016405b41604091206c61603085208fa0df0130912cb14cd187914b009e306440a3018ca0c5810c305400507103b1113016c0ead00100e3f02b6003410981cdf04c50d0213d61984110c0ba700ae0c8912f618a01a231bc81066010a1d051242103013ac05c30dae14030f890e1117b319a002a707f30923',
    prv: 'd112525a9435c29d732592e9ec90eba2ae7b1ae2c0d3ac9b6d6ce662ca5140abb02bc846c7f54f955a84fed543107c9180366d025324aac2d253ec60515cf9ee',
    address: '1826d3782d53b127c53129fe67f4a3e3c1140feb2af36a0517077297a6e867e5'

}

Also, if you want to find more interesting use cases — see our tests with these accounts here:

KlyntarCore/postQuantumTxs.js at main · KLYN74R/KlyntarCore

As before — more examples are available in our documentation. Here you will learn how to generate and how to sign transactions, as well as how to use PQC in smart contracts

Post-quantum transactions | KLYNTAR Docs

Summary

As you see, we worked realy hard to bring different interesting crypto primitives to KLYNTAR. Thanks to this, you can easily generate a quick ed25519 address that can be used even on your Solana apps, or you can write a WASM / EVM smart contract with BLS / TBLS abilities usage. And as a dessert — you can use super secured post-quantum cryptography to be ready for the epoch of quantum computing⚛️

Technologies first — hype after. That’s the rule

Follow us on different platforms to get updates ASAP🤖

Links

1. https://landing.klyntar.org
2. https://twitter.com/KLYN74R
3. https://github.com/KLYN74R
4. https://docs.klyntar.org
5. https://discord.com/invite/f7e7fCp97r