# Introduction Greetings, dear tester. Jun 15th, 2024, we have published the first BETA of the YAR, which you can try out for yourself. We are working to make your YAR testing experience as enjoyable as possible, however, please be aware of the fact that this is a beta and many of the features and usage practices are not perfected. Please read the instructions below, which we have carefully compiled especially for you. Following it, you can, without anyone else's help get acquainted with the current functionality of the future project. ### Quick Links {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} Upvote Us {% endembed %} {% embed url="" %} Explain Video {% endembed %} {% embed url="" %} YAR presentation | From IDEA to PRE-BETA {% endembed %} {% embed url="" %} {% content-ref url="/pages/aJBwlPeNLdVnNTOUwObn" %} [WhitePaper](/whitepaper/introduction) {% endcontent-ref %} # Add YARchain TestNet * Open any Metamask or Trust available browser, go to [Explorer](https://explorer.testnet.yarchain.org/), scroll page down, and pick the "Add YAR testnet". * — OR — * Open MetaMask > Select Network > Add Network > Add Network Manually * Network name: YARchain TestNet * New RPC URL: * Network ID: 10226688 * Currency Symbol: tYAR * Block explorer URL: * Save button * Add some coins and tokens with [YARtestnet Faucet](https://faucet.testnet.yarchain.org/) # Add a few others TestNets To send data and tokens from external networks, add those networks to your EVM-compatibility wallet and get some free coins and tokens from faucets. ### **Supported chains:** * YARchain (TestNet) * Ethereum Sepolia * Polygon Amoy * Optimism Sepolia * Avalanche Fuji * Base Sepolia * SKALE Europe * Binance Smart Chain (TestNet) {% hint style="warning" %} Currently YAR supports all EVM-based blockchains (it is about 230 chains), but it is tough to find test coins for not-so-popular but still valued networks. If you have some free coins of any (listed or unlisted) EVM-based chain, please share them with us. Just donate it on **0x51155c8E42b1d0caEF3A0c6653d7b18db384d38f** and send a message with the "[Bridge Message](https://connect.testnet.yarchain.org/apps/message)" from the Donated address to the "Receive on YARchain TestNet: **0x51155c8E42b1d0caEF3A0c6653d7b18db384d38f** address. Enter the BlockchainName that you donated or the BlockchainName that you want to add to the YAR interconnector. {% endhint %} # YAR v.1.0beta — Rewarding Usage Experience After adding the necessary networks and getting free coins and erc20 tokens, you need to go to the interface of the interconnector: {% embed url="" %} {% hint style="info" %} *On Jun 4th, 2024 the interconnector supports transferring all types of data, coins, tokens, messages, etc in chain-2-chain and chain-2-multichain modes.* {% endhint %} On this site, you need to connect your wallet - "Connect Wallet" (Rainbow, Coinbase Wallet, Metamask, or any other wallet that supports "Wallet Connect"). #### For Native Token (coin) cross-chain transferring: * Go to: [Apps](https://connect.testnet.yarchain.org/apps) > [Bridge Native Tokens](https://connect.testnet.yarchain.org/apps/native) * Enter "Reciever address" (the address that gets tokens after transfer) * Choose the network from which you are sending the token: "Send from" #### For erc20 tokens cross-chain transferring * Go to: [Apps](https://connect.testnet.yarchain.org/apps) > [Bridge EIP-20](https://connect.testnet.yarchain.org/apps/erc20) * Enter "Reciever address" (the address that gets tokens after transfer) * Choose the network from which you are sending the token: "Send from" * Enter "Send amount" * Choose a network that the token is being sent to: "Recieve to" #### For erc721 tokens cross-chain transferring: * Go to: [Apps](https://connect.testnet.yarchain.org/apps) > [Bridge NFT EIP-721](https://connect.testnet.yarchain.org/apps/erc721) * Enter "Reciever address" (the address that gets tokens after transfer) * Choose the network from which you are sending the token: "Send from" #### For erc1155 tokens cross-chain transferring: * Go to: [Apps](https://connect.testnet.yarchain.org/apps) > [Bridge NFT EIP-1155](https://connect.testnet.yarchain.org/apps/erc1155) * Enter "Reciever address" (the address that gets tokens after transfer) * Choose the network from which you are sending the token: "Send from" #### For message cross-chain transferring: * Go to: [Apps](https://connect.testnet.yarchain.org/apps) > [Bridge Message](https://connect.testnet.yarchain.org/apps/message) * Choose the network from which you are sending the message: "Send from" * Choose the network to which you are sending the message "Recieve to" * Enter "Reciever address" (the address that gets a message after transfer) * Enter your message in "Message" area. * Pick up the "Transfer" button. # Protocol The YAR protocol implements a network for delivering on-chain transactions to external networks.\ It consists of the following elements: 1. A standard EVM transaction that needs to be delivered 2. The `YarRequest` smart contract, which serves as the entry point 3. The `YarResponse` smart contract, responsible for on-chain transaction delivery 4. The `YarHub` the smart contract, located only in YarChain, represents a mempool of cross-chain transactions 5. The Solidity structure `YarLib.YarTX`, a wrapper around a standard EVM transaction with additional metadata 6. The EVM-compatible blockchain YarChain 7. A network of validators known as Relayers These elements are combined in the following sequence: 1. The initiator (EOA wallet or smart contract) calls `YarRequest.send(...)` 2. `YarRequest` generates a `Send` event 3. Upon receiving the `Send` event, Relayers add the pending transaction to `YarHub` 4. After adding the transaction to the queue, Relayers move transactions into execution, locking a sufficient amount of fees 5. Relayers call `YarResponse.deliver(...)`, which executes the transaction to the destination address 6. After executing the transaction, Relayers update the transaction status and return any unspent fees ### 0. Standard EVM Transaction There are no restrictions on the transactions being sent: 1. The address in the external network does not need to conform to any specific interface; transactions can be delivered even to EOA wallets 2. The transaction can transfer the native token, i.e., use the \[value] parameter 3. The transaction can represent another cross-chain call, allowing complex sequences of data transfers across multiple networks ### 1. `YarRequest` Smart Contract The starting point of the protocol. It is responsible for sending events to validators. There are 3 types of unique events: 1. `Send` - sends a cross-chain transaction ```solidity event Send( YarLib.YarTX yarTx ); ``` 2. `Deposit` - replenishes the balance, which is debited to pay for cross-chain transactions ```solidity event Deposit( address depositor, address feesToken, uint256 amount ); ``` 3. `Approve` - similar to `EIP20.approve`. Allows applications to debit the user's balance to pay for their cross-chain transaction ```solidity event Approve( address account, uint256 initialChainId, address spender, uint256 amount ); ``` Each event corresponds to a function of the same name: 1. `send` - accepts `YarLib.YarTX` and sends it to the Relayers network ```solidity function send(YarLib.YarTX memory yarTX) external returns (YarLib.YarTX memory); ``` 2. `deposit` - accepts tokens (native or EIP20) from the user ```solidity function deposit(uint256 amount) public payable; ``` 3. `approve` - allows the \[spender] to debit \[amount] YarToken from the user's deposit ```solidity function approve(address spender, uint256 amount) public; ``` ### 2. `YarResponse` Smart Contract Acts as the entry point for sending transactions by the Relayers network. This is done via the `deliver` function, which deploys the cross-chain transaction \[yarTx] and delivers it to the recipient. ```solidity function deliver(YarLib.YarTX calldata yarTx) external payable { ... yarTx.target.call{ value: yarTx.value }(yarTx.data); ... } ``` Additionally, this smart contract is used by applications for authorization if their recipient function should only accept calls from Relayers and not any address. Temporarily, it stores the metadata of the current cross-chain transaction, which can be accessed in the `trustedYarTx` function. The metadata is recorded before the call and deleted immediately afterward. ```solidity function trustedYarTx() external view returns (YarLib.YarTX memory); ``` !!! Passing flags to enable/disable writing `trustedYarTx` fields to storage can save gas. ### 3. `YarHub` Smart Contract `YarHub` stores all pending, executed, and unexecuted cross-chain transactions, which are accessible in the `wrappedYarTXs` mapping. ```solidity function wrappedYarTXs(bytes32 yarTxHash) external view returns (WrappedYarTX); ``` To access a specific transaction `[yarTx]`, the key used is the keccak hash of the entire `YarLib.YarTx` model. ```solidity keccak256(abi.encode(yarTX)) ``` You can also obtain the identifying hash of a cross-chain transaction using the `[YarHub.getYarTxHash]` method. ```solidity function getYarTxHash(YarLib.YarTX calldata yarTX) public pure returns (bytes32); ``` `YarHub` also stores user deposits in Yar tokens, which are used to pay for transaction fees.\ The balance is credited to the deposit only from the relayer’s address after processing the `Deposit` event.\ To view the current balance: ```solidity uint256 balance = yarHub.deposits(account); ``` ### 4. Solidity Structure `YarLib.YarTX` ```solidity library YarLib { struct YarTX { uint256 initialChainId; // Identifier of the current network address sender; // Your smart contract [Example] address payer; // User who calls the Example contract and pays the fee in Yar uint256 targetChainId; // Identifier of the network where the transaction will be delivered address target; // Address in the [TARGET] network where the transaction will be called uint256 value; // Amount of the native token of the [TARGET] network that will be sent with the transaction bytes data; // Encoded transaction data (bytes4 for the function signature + function arguments) uint256 _nonce; // This parameter will be redefined in YarRequest; set it to 0 } } ``` # Fees To pay for gas in the delivery network, the protocol charges a sufficient amount in Yar tokens from the user's balance, stored on the YarHub smart contract in the Yar network.\ For the Relayers network to execute the transaction, the user must first deposit a sufficient amount.\ If the user does not have a sufficient deposit at the time of transaction execution, the transaction will remain in the queue.\ This is done by calling the `deposit` function on the `YarRequest` smart contract from any supported network. ```solidity yarRequest.deposit(amount); ``` Each network uses its own payment token, usually the native token of the network, but it can also be an EIP20 token.\ To see which token is used: ```solidity address feeToken = yarRequest.feeToken(); ``` If `feeToken == address(0)`, the native token of the network is used; otherwise, the specified EIP20 token is used. For example, by calling `YarRequest.deposit(1e18)` on the Ethereum network, 1 ETH will be debited from the user's wallet, which will then be converted at the current rate into YAR tokens and credited to the user's deposit in `YarHub`. To perform cross-chain transactions from the address of any smart contract but pay the Yar fee from the user's address, the user must allow the application to debit the deposit on their behalf. ```solidity yarRequest.approve(appAddress, yarAmount); ``` # Use cases {% hint style="info" %} More cases can be found here: [https://github.com/YARlabs/YAR-v2-contracts/](https://github.com/YARlabs/YAR-v2-contracts/tree/main) {% endhint %} The YAR protocol allows sending arbitrary transactions to any address, whether it's a smart contract or an EOA wallet. ### Sending Transactions to an EOA Wallet Such transactions usually only make sense when transferring the native token of the network, the amount of which is specified in the `value` parameter. For example, a standard transaction within one network: ```typescript sender.sendTransaction({ from: sender.address, // sender to: recipient.address, // recipient value: 1e18, // amount of funds sent }) ``` To deliver a similar transaction to another network, it looks like this: ```typescript yarRequest.send({ initialChainId, sender: sender.address, // sender payer: sender.address, // sender targetChainId, target: recipient.address, // recipient value: 1e18, // amount of funds sent data: '0x', _nonce: 0, }) ``` After executing this transaction, the Relayers network will transfer 1e18 of the target network's native tokens to the recipient's address. ### Sending Transactions to a Smart Contract Sending transactions to an arbitrary smart contract makes sense when the called method does not depend on the `msg.sender` address. For example, the address is passed in the arguments, or it involves meta-transactions or account abstraction. For example, a standard transaction within one network: ```typescript sender.sendTransaction({ from: sender.address, // sender to: smartContract.address, // called smart contract value: 0, // amount of funds sent data: '0x11111...' // encoded transaction }) ``` To deliver a similar transaction to another network, it looks like this: ```typescript yarRequest.send({ initialChainId, sender: sender.address, // sender payer: sender.address, // sender targetChainId, target: smartContract.address, // called smart contract value: 0, // amount of funds sent data: '0x11111...', // encoded transaction _nonce: 0 }) ``` By executing this transaction, the `YarResponse` smart contract will parse the bytes from `data` and call the specified function at the `target` address. You can also pass the `value` parameter with this transaction if needed. Here's the English translation of the provided Russian text, formatted for a programming context: *** ### Cross-Chain API The main potential of the Yar protocol lies in enabling communication between smart contracts of the same application located on different networks.\ Create an empty smart contract: ```solidity contract Example { } ``` Register the addresses of \[YarRequest] and \[YarResponse] in the smart contract: ```solidity contract Example { address public yarRequest; address public yarResponse; constructor( address initialYarRequest, address initialYarResponse ) { yarRequest = initialYarRequest; yarResponse = initialYarResponse; } } ``` To send a cross-chain transaction from a smart contract, the \[YarRequest] will require the data model \[YarLib.YarTX]. ```solidity library YarLib { struct YarTX { uint256 initialChainId; // Identifier of the current network address sender; // Your smart contract [Example] address payer; // User who calls Example and pays the fee in Yar uint256 targetChainId; // Identifier of the network where the transaction will be delivered address target; // Address in the [TARGET] network where the transaction will be called uint256 value; // Amount of the native token of the [TARGET] network to be sent with the transaction bytes data; // Encoded transaction data (bytes4 for the function signature + function arguments) uint256 _nonce; // This parameter will be redefined in YarRequest; set it to 0 } } ``` Import `YarLib` into your smart contract: ```solidity import { YarLib } from "./YarLib.sol"; contract Example { ... } ``` Develop a receiver function that will accept a string of data. Two checks are required to identify the senders: 1. Check that `msg.sender` equals the `yarResponse` address. 2. Check that `yarTX.sender` equals the address of your smart contract from the initial network. ```solidity contract Example { string public lastMessage; function exampleReceiveMessage(string calldata message) external { require(msg.sender == yarResponse, "only yarResponse!"); YarLib.YarTX memory yarTx = YarResponse(yarResponse).trustedYarTx(); // Check against address(this) // - This will work if both smart contracts have the same address // If your smart contracts have different addresses, you will need to register them separately require(yarTx.sender == address(this), "only app!"); lastMessage = message; } } ``` Example of registering the addresses of your applications from external networks: ```solidity contract Example { mapping(uint256 chainId => address peer) public peers; function setPeer(uint256 newChainId, address newPeer) external { require(msg.sender == owner, "only owner!"); peers[newChainId] = newPeer; } function getPeer(uint256 _chainId) public view returns (address) { address peer = peers[_chainId]; return peer == address(0) ? address(this) : peer; } function exampleReceiveMessage(string calldata message) external { require(msg.sender == yarResponse, "only yarResponse!"); YarLib.YarTX memory yarTx = YarResponse(yarResponse).trustedYarTx(); require(yarTx.sender == getPeer(yarTx.initialChainId), "only app!"); ... } } ``` Now, to make this function callable from another network, implement a message-sending function. ```solidity contract Example { function exampleSendMessage( string calldata message, uint256 targetChainId ) external returns(YarLib.YarTX) { ... } } ``` Where `message` is the message to be sent\ `targetChainId` is the network where the message will be delivered\ `returns(YarLib.YarTX)` is used in simulation for gas estimation. Encode the call to the \[exampleReceiveMessage] function: ```solidity bytes memory encodedTX = abi.encodeWithSelector( Example.exampleReceiveMessage.selector, message ); ``` Then create `YarTX`: ```solidity YarLib.YarTX memory yarTx = YarLib.YarTX( block.chainid, address(this), // if your applications have identical addresses msg.sender, targetChainId, targetAddress, 0, encodedTX, 0 ); ``` or ```solidity YarLib.YarTX memory yarTx = YarLib.YarTX( block.chainid, getPeer(targetChainId), // to get the address of your application in the target network msg.sender, targetChainId, targetAddress, 0, encodedTX, 0 ); ``` Next, send this model to `YarRequest`: ```solidity contract Example { function exampleSendMessage( string calldata message, uint256 targetChainId ) external returns(YarLib.YarTX) { bytes memory encodedTX = abi.encodeWithSelector( Example.exampleReceiveMessage.selector, message ); YarLib.YarTX memory yarTx = YarLib.YarTX( block.chainid, address(this), // if your applications have identical addresses msg.sender, targetChainId, targetAddress, 0, encodedTX, 0 ); // Send the transaction // Returning the model can be useful for transaction simulation and fee estimation return YarRequest(yarRequest).send(yarTX); } } ``` Now, for the user to send a transaction from one of your smart contracts to another in an external network, they must have a balance in YarHub. The balance can be topped up through `YarRequest`: ```solidity yarRequest.connect(user).deposit(nativeTokenAmount); ``` Next, grant permission to your application to spend funds: ```solidity yarRequest.connect(user).approve(yourAppFromInitialChainAddress, yarAmount); ``` Then, call your application: ```solidity example.connect(user).exampleSendMessage('Hello!', targetChainId); ``` The rest will be handled by the YAR network. First, the deposit will be credited in YarHub: ```solidity yarHub.connect(relayers).deposit(user.address, yarTokenAmount); ``` Next, permission will be recorded for the transfer to the application: ```solidity yarHub.connect(relayers).approve(user.address, initialChainId, yourAppFromInitialChainAddress, yarTokenAmount); ``` Then, the user's transaction will be added to the queue: ```solidity yarHub.connect(relayers).createTransaction(yarTX, initialNativeTxHash); ``` After that, the transaction will be processed, temporarily locking sufficient funds on the user's deposit to complete the transaction: ```solidity yarHub.connect(relayers).executeTransaction(yarTX, feeTokensToLock); ``` Finally, the YAR network will deliver the transaction to the target network: ```solidity yarResponse.connect(relayers).deliver(yarTX); ``` In the target network, the `YarResponse` smart contract will execute the transaction: ```solidity yarTx.target.call{ value: yarTx.value }(yarTx.data); ``` # Hello world! Example of a smart contract for cross-chain message transfer {% hint style="info" %} More examples can be found here: [https://github.com/YARlabs/YAR-v2-contracts/](https://github.com/YARlabs/YAR-v2-contracts/tree/main) {% endhint %} ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity 0.8.20; import { YarLib } from "../../YarLib.sol"; import { YarRequest } from "../../YarRequest.sol"; import { YarResponse } from "../../YarResponse.sol"; contract YarBridgeMessage { address public owner; uint256 public chainId; address public yarRequest; address public yarResponse; mapping(uint256 chainId => address peer) public peers; function setPeer(uint256 newChainId, address newPeer) external { require(msg.sender == owner, "only owner!"); peers[newChainId] = newPeer; } function getPeer(uint256 _chainId) public view returns (address) { address peer = peers[_chainId]; return peer == address(0) ? address(this) : peer; } constructor( address intialYarRequest, address intialYarResponse ) { yarRequest = intialYarRequest; yarResponse = intialYarResponse; chainId = block.chainid; owner = msg.sender; } function sendTo( uint256 targetChainId, address receiver, string memory message ) external returns (YarLib.YarTX memory) { bytes memory targetTx = abi.encodeWithSelector( YarBridgeMessage.sendFrom.selector, msg.sender, receiver, message ); YarLib.YarTX memory yarTx = YarLib.YarTX( chainId, address(this), msg.sender, targetChainId, getPeer(targetChainId), 0, targetTx, 0 ); YarRequest(yarRequest).send(yarTx); return yarTx; } struct Message { address sender; address receiver; string message; uint256 timestamp; } Message[] public messages; uint256 public messageCount; function getMessages(address receiver, address sender, uint offset, uint limit) public view returns (Message[] memory) { require(offset < messageCount, "Offset out of range"); uint end = offset + limit; if (end > messageCount) { end = messageCount; } uint resultSize = end - offset; Message[] memory result = new Message[](resultSize); uint index = 0; for (uint i = messageCount - offset; i > messageCount - end; i--) { if (messages[i - 1].receiver == receiver) { result[index] = messages[i - 1]; index++; } else if (messages[i - 1].sender == sender) { result[index] = messages[i - 1]; index++; } } return result; } function sendFrom( address sender, address receiver, string calldata message ) external { require(msg.sender == yarResponse, "Only YarResponse!"); YarLib.YarTX memory trustedYarTx = YarResponse(yarResponse).trustedYarTx(); require(getPeer(trustedYarTx.initialChainId) == trustedYarTx.sender, "not peer!"); messages.push(Message( sender, receiver, message, block.timestamp )); messageCount++; } } ``` # Introduction {% hint style="info" %} Decentralized solutions for liquidity migration between blockchains are absolutely essential in today's market. Centralized solutions often fall short in terms of security, transparency, and accessibility, making them a risky option for investors. On the other hand, decentralized solutions offer unparalleled security and transparency, which are crucial for maintaining investor trust and confidence. Furthermore, decentralized solutions provide investors with greater flexibility and accessibility, allowing them to move their assets more easily and efficiently between different blockchains. This results in increased liquidity and reduced transaction costs, both of which are vital for the growth and sustainability of the market. In conclusion, a decentralized solution for liquidity migration between blockchains is not just a good option, it is a must-have for creating a robust and secure financial ecosystem. There is no doubt that the blockchain industry can only thrive and succeed in the long term with such a solution in place. {% endhint %} The complexity of using powerful decentralized solutions is determined by the large number of centralized services that simplify and speed up the use of blockchain technology. At the same time, we see an exponentially growing demand for decentralized solutions. The only thing that hinders the widespread use of blockchains is the lack of a single industry standard for information exchange, a universal solution for interaction between networks, and liquidity migration. This obvious need formed the basis of the YAR project. YAR is a decentralized blockchain interconnector, a modular solution for liquidity migration between blockchains. ### Quick links {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} Upvote Us {% endembed %} {% embed url="" %} Explain Video {% endembed %} {% embed url="" %} YAR presentation | From IDEA to PRE-BETA {% endembed %} {% embed url="" %} {% content-ref url="/pages/PLYvD0UwMnIkNQrylLyV" %} [TestNet Instruction](/) {% endcontent-ref %} # YAR architecture YAR consists of three decentralized solutions - YAR chain, YAR protocol, and YAR vault: * The **YAR chain** ensures the operation of smart contracts; * The **YAR protocol** stores a set of connectors that ensure the interaction of smart contracts deployed in the YAR chain with external sources, objects, and subjects of those sources; * The **YAR vault** creates and stores private TSS keys YAR protocol. YAR allows the developer to create smart contracts by connecting any number of available blockchains to them, and work with coins, tokens, smart contracts, and any other objects and entities as if all this was directly available in the ecosystem. At the same time, the requirements of reciprocity, consistency, and decentralization are observed. An important aspect, by creating a smart contract in YAR, the results of its work can be used in any other connected blockchain, which will lead to an increase in the interoperability of all blockchain networks in the future. # YAR objective The main task of YAR is to provide communication (interoperability, compatibility) between all existing and new blockchain networks. Theoretically, blockchain interoperability is defined as the ability of blockchains to transfer information from one to another. In other words, a transaction or state transition in one network may depend on a transaction or state transition in another network. It is worth noting that initially blockchains were developed as autonomous, self-sufficient decentralized registries in which the reliability of state transitions, i.e. transactions, and blocks, depends only on the history of the blockchain itself (without taking into account external factors). In this way, interoperability goes beyond the autonomy that underpins the platform. Polkadot and COSMOS allow the creation of blockchains that can exchange information with each other, but this does not solve the problems of interoperability with other networks, such as Bitcoin, Ethereum, Solana, and TRON. What are the interoperability requirements for blockchains (for this connection to be reliable and secure)? * **Reciprocity**: when there's an interaction between blockchains whose result is applied in both or none of the blockchains; * **Consistency**: interconnected blockchains have a certain history that's consistent across both blockchains. In practice, this ensures the secure transfer of tokens/coins/data between blockchains; * **Decentralization**: decisions during interoperability shouldn't depend on a trusted party, and an interoperability protocol should describe signals that determine actions within the communication. # YARchain architecture {% hint style="warning" %} This is a schematic representation of the operation of the entire ecosystem using the example of chain-2-chain asset transfer. {% endhint %}

Chain-2-chain asset tranfering

{% hint style="info" %} You can familiarize yourself with the connector operation diagram in the next section. {% endhint %} # Connectors architecture
# Project mechanics YAR is a modular infrastructure for cross-chain connectivity. YAR consists of three main parts: YAR chain, YAR protocol, and YAR vault, which work together to provide a developer with a single standardized input/output point for all supported systems (Bitcoin, Ethereum, TRON, BSC, Solana, etc.). # Nodes Anyone can become a validator node. They send a predetermined amount of YAR to a smart contract that confirms ownership of funds and node status as a YAR chain validator node. Validator Nodes are randomly selected to confirm the next block. Nodes are called every 2 minutes to keep up to date. Nodes that don't respond to the calls are excluded from block verification for the next 2 minutes. This ensures that the asset swap service is always available for users. It also prevents multiple people from gaining full control of the network. ### Node technical requirements **Minimum:** 1. CPU: 2 CPUs 2. RAM: 4 GB 3. Storage: 40 GB **Optimal:** 1. CPU: 4 CPUs 2. RAM: 12 GB 3. Storage: 80 GB ### Network management Nodes participate equally in network management by voting for/against the introduction of changes. Decisions are made by a simple majority within a period not exceeding 7 days. The validator nodes can change the rules of the system. However, they cannot decide which transactions can be performed or which platforms are supported. Of course, Validator nodes remain anonymous in the network. A node cannot talk to another node or find out who controls another node. Validator nodes receive a reward for each block and cannot claim a reward when a node is offline. \
# Chain Connection ### Two-way secure state management YAR chain is connected to networks like Bitcoin and Ethereum via bidirectional security busses of the YAR protocol. This means that subjects and objects in networks may or may not be bound to subjects and objects in other networks. State management only synchronizes the state of a transaction or linked smart contract on the external network. Specifically, the system tracks: * which part of an object has been moved; * associated information such as the transaction ID; * the address of the sender; * the address of the person receiving the asset. It's worth noting that only information about YAR-related transactions is synchronized, but not every transaction in the external network. To make this possible, code must be written for each connected network, the so-called "network connectors", which describe possible scenarios for working with objects and subjects of the external network. # Witness operations When a node sees a transaction on a connected network, it writes it to what's called a "witness transaction". A witness is a message from a node that says, "I saw that". So it could be: * "I saw someone send 1 BTC to YAR "; * "I saw someone change the status of data on YAR "; * Or, "I saw someone change the status of a smart contract on YAR ". All nodes send witness transactions to the system all the time. Witness transactions have a standard structure, regardless of which network they originate from. A Bitcoin transaction is different from a BNB SmartChain transaction, but in YAR they look the same. # Consensus on transactions When witness transactions arrive, the network must process them and decide which ones are correct. To reach an agreement on a transaction ID, the network looks through all relevant witness transactions. If the network determines that 55% of the nodes agree with a transaction, it's approved and considered correct. ### Managed storage (keeper) YAR protocol manages different types of stores (keepers): * **Transferable Asset Keeper** - stores coins and tokens, including NFT; * **Non-Transferable Asset Keeper** - stores the dynamic state of a smart contract; * **Data Keeper** - catalogs asset owners of previous Keepers. Keepers aren't custodians - all outgoing transactions are processed by the system and initiated only by an asset owner. Nodes cannot withdraw funds. Stores are designated by the Threshold Signing Scheme (TSS). TSS requires that 55% of nodes approve a transaction to leave the store. Each connected chain has a primary store for storing incoming funds and multiple secondary stores for sending funds. Each YAR protocol port is connected to each primary store and some secondary stores. ### Receiving and transferring assets To send assets to YAR, liquidity providers must first obtain the current address of the main storage in that network. They request this information from several different nodes. This prevents a spoofed address from being sent - a "spoofing attack." Once the assets are sent, the nodes receive a modified address status code and/or smart contract and enter the money into the main storage address. They create witness transactions and send them to the network, assigning an asset to an owner and simultaneously minting the asset in the YAR chain. When an asset needs to be sent to the external network, a node invokes a secondary storage selection algorithm. This checks whether a sender owns an asset and has the resources to send an external asset. This is important when working with tokens from networks that require payment in the network's currency for a transaction. ### Storage balance and life support In preparation for an outgoing transaction, the network looks for secondary storage with sufficient assets. To ensure that the store has sufficient assets for outgoing transactions, it's automatically replenished periodically. Typically, half of the assets for the pool are stored in the main storage and the other half in the secondary storage. The main storage is replenished every few days as part of the keep-alive protocol. This can also happen more frequently, such as when the network connection requests an update. Secondary storage is also rebuilt when one of the supporting nodes leaves the network. Cyclic stores ensure that they always have a minimum number of active nodes. # Threshold Signature Scheme (TSS) Threshold cryptography is one of the most secure methods for performing cryptographic operations. To understand, cryptography is a field of computer science that creates the conditions for secure and confidential communication between two or more parties without outside influence. In practice, cryptographic methods aim to receive, transmit, and store confidential information in encrypted form between interested parties to prevent other individuals, organizations, or programs from obtaining the data. Cryptography aims to create secure ecosystems. In 1994, [Alfredo et al.](https://dl.acm.org/doi/10.1145/195058.195405) proposed one of the first security-related systems based on threshold cryptography. Initially, the only significant threshold users of cryptosystems were military governments and organizations that held sensitive information. Threshold cryptosystems protect information by encrypting and distributing secrets among a group of independent computers that are classified as fault-tolerant. Fault tolerance is the ability of a system to continue operating despite failures or malfunctions. As the name implies, threshold cryptography allows individual keyholders to encrypt a secret in such a way that no keyholder can open a lock individually. Instead, a minimum number of keyholders among all keyholders (a threshold number) is required to decrypt the secret. A minimum threshold can be used to guarantee that a secret remains secure even if some of the participants collude. Essentially, threshold cryptography ensures that one person doesn't have complete power, which can lead to vulnerabilities in the system. It also ensures that a secret can be revealed even if one or more people are not available and that there are no bottlenecks. This makes the system fault tolerant. Key signing occurs when nodes need to approve an outgoing transaction from secondary storage. A transaction is first submitted to a specific store for approval. Nodes that support that store are ready to sign a transaction. When there are enough nodes, the output begins. When it's ready, all nodes attempt to send the transaction to a connected network. One of them is accepted. Code is required to translate this outgoing message from the YAR format to an external network. ### Preventing attacks During key generation, each node verifies that other nodes haven't done anything wrong. The system also ensures that nodes don't cheat by using a commit authorization scheme. This ensures that nodes cannot cheat the system by saying one thing, accepting it, and then quickly changing it in their favor. Key signing prevents fraud because nodes only sign messages that are outside the network. # Scaling ### Limitations of TSS mission Together with the YAR protocol, the YAR chain controls the main memory - the YAR vault. This consensus can only grow so large, making TSS too slow. As soon as the key generation process takes too long, the main memory is divided by 2. This process is repeated until the network reaches either the "block consensus limit" or the "economic limit" described below. ### Block consensus limit The YAR chain is based on the PoS consensus. The target rate for creating new blocks is 5 seconds or 15Mb. When a block size reaches 15Mb, a block is validated, no matter how much time has passed since a previous block. This is to increase the speed of the blockchain during peak loads. ### Economic limit The blockchain strives to be decentralized, so it does not limit the number of nodes that can participate in block validation. At the same time, the dominant consensus of the network is PoS, so there is a local limit on the number of nodes, which is calculated by the formula: [total circulating coins / staking size = local maximum number of nodes](#user-content-fn-1)[^1] The validator's reward is calculated by the formula: [2YAR (block validation reward) + transaction fee = validator reward](#user-content-fn-1)[^1] The consensus takes into account the need to manage the economy of the network. Therefore, the staking amount, the reward for block validation, and the inclusion/exclusion of transaction fees in the reward to the validator can be reduced/increased by voting by the participants of the YAR DAO. [^1]: # Management ### Electronic voting (including YAR DAO) According to [Gallegos-Garcia et al.](https://scholar.google.com/citations?user=pRru5o4AAAAJ\&hl=es) in a 2009 [paper](https://scholar.google.com/citations?view_op=view_citation\&hl=es\&user=pRru5o4AAAAJ\&citation_for_view=pRru5o4AAAAJ:xtRiw3GOFMkC), the security of electronic voting protocols must evolve to ensure true democracy. Previous security algorithms for electronic elections were always based on public-key procedures. However, this paper proposes to secure electronic election protocols with threshold cryptography and blind signatures as a more cost-effective alternative. Threshold cryptography and blind signatures aren't only less expensive and provide better confidentiality, accuracy, and reliability. Another paper "[Practical Electronic Voting Protocol Using Threshold Schemes](https://www.researchgate.net/publication/2663036_A_Practical_Electronic_Voting_Protocol_Using_Threshold_Schemes)", presents a new secret ballot voting procedure that fully meets the requirements of large-scale elections. Voting participants are an initiator, a voter, and vote counters. The procedure uses threshold encryption to protect the confidentiality and accuracy of votes against the dishonesty of the election initiator, the voters, and the vote counter. If done well, it can ensure the verifiability, fairness, and validity of the election process, and neither the election initiator, voters, nor the vote counter can lead to a miscount, influence the election results, or spoiler disrupts the election. # Voting in YAR DAO Voting participants have authorized rights of the network and rights as network validators. That is, the number of votes fully corresponds to the number of nodes. All DAO members have equal rights, and everyone can propose a change and vote for it. YAR DAO participants have the following voting options: 1. **Text voting** - any proposed issue, the result of a vote not in the meeting. 2. **Vote to Change the Deadline and Quorum of Pending Votes** - New conditions for making voting decisions will be recorded for a new vote after this vote is completed. By default: Quorus - 50+%, voting period - unlimited. 3. **Voting to change the validator reward** - block validation reward + transaction fee - these parameters can be revised up or down or excluded from the validator reward. There is also a procedure for full or partial remuneration. Default: 2YAR + transaction fee. 4. **Staking amount** - The number of coins that are required for staking to get a validator node. Default: 200'000YAR 5. **Validator coin staking period**. By default: 1 year. 6. **DAO wallet management** (withdrawals). 7. **Return the node after blocking**. 8. **Marking a blockchain connector as certified**. 9. **The cost of a byte of transmitted information** in the network is a commission for users' transactions. ### Terms and conditions of voting: Each vote has a decision time limit and a decision quorum. These parameters can be global variables and do not change without voting validators. **Deadline** - the number of days before the end of the voting **A quorum** is the number of votes required to make a decision. **A possible option is a simple majority** of those who voted at the time of voting. **For example**, the number of nodes is 50, the voting period is 7 days, without specifying a quorum, and only 10 nodes will vote in 7 days, 6 of which will make a positive decision, then the vote will be considered completed and approved. # Supported networks If a community wants to support a new chain, developers can write a "connector" that connects them to the YAR protocol. Once the code is submitted, it's tested and reviewed by the main development team. If accepted, it's added to the main protocol that all nodes work with - the main binary. Whenever nodes are taken off the network, they update their software. When 55% of nodes use a new port and observe a new network, it's added to the available sources. To delist, nodes remove the connector from a supported list. When 55% no longer observe/listen to the Connector, it's removed. The process starts and the assets of this chain are returned to their owners. # Protocol updates There are 3 main components of the software on which the nodes run: * **YAR chain** - operates and manages a blockchain; * **YAR protocol** - runs and manages the interoperability protocol and stores key values; * **YAR vault** - a network software - stores the key generation and signature of the TSS protocol. The software is updated when the validator nodes have voted for the network update and are disconnected from the network for the update. At the time of the update, they don't receive any compensation and can be excluded from the list of Validator Nodes for up to 2 minutes. In addition, there are versions of the YAR chain and YAR protocol. When a node wants to register, it must be informed which versions it's using. The network can select them if they're using software that's more recent than 55% of the active nodes. When the network software is updated, the validation nodes first agree on a specific block number in the future when the update occurs. When the network reaches this point, the entire chain stops working. A "genesis import" to a new network is created and the old network is shut down. # Use cases
### Use case #1 - exchange contract "If you give me $100 in BTC, I'll give you $100 in ETH" Side A offers to exchange assets with side B for $100. Side A wants to sell BTC to Side B and receives ETH as a result of the transaction. Side A creates a contract in a no-code smart contract constructor, specifying the currencies involved in the transaction and the exchange rate, and offers the contract to Side B. The contract is signed by Side A. Side B agrees to honor this contract. Side A is then given an address on the Bitcoin network to which it can send BTC in a specified amount, and Side B is given an address on the Ethereum network and the amount to send in ETH. After sides A and B send assets, the smart contract verifies receipt of the assets and mints wrapped tokens in the amount received to the addresses of the sides. ### Use case #2 - crowdfunding contract Side A announces a round of contributions in BTC, ETH, LTC, and TRX. At the same time, Side A issues tokens on the BSC blockchain and sends 30% of the collected funds to the liquidity pool of the TOKEN /USDC pair on PancakeSWAP. Side B wants to buy a token. To do so, it selects the currency in which it wants to make a payment and the address of the wallet on the BSC network to which it wants to receive tokens in the smart contract interface. Before starting the smart contract, it checks the availability of funds for transactions on the BSC network. Then, the contract creates an address on the Bitcoin network to which the money should be transferred. After side B sends the amount, it recalculates the amount received by the number of tokens, sends it to side B at the previously specified address, and coins the wrapped BTC into side B's wallet. 30% of the amount is exchanged for USDC and sent in pairs to the smart contract in PancakeSWAP, which in return receives LP tokens and coins them into side A's wallet in the YAR chain. ### Use case #3 - real estate sale contract Side A announces the sale of 100 apartments. Each apartment has several unique characteristics, such as the floor, the area, the view from the window, the degree of readiness for occupancy, etc. Therefore, each apartment is issued in the form of an NFT, with the transfer of rights through the sale utilizing a corresponding contract. At the same time, Side A offers authorized intermediaries (from a predetermined list) a commission of 5% of the price if the sale is made with their help. Side A announces the supported currencies for payment and the currency in which the final payment will be made. An authorized broker prepares an offer for side B, which is interested in buying a certain apartment. If everything is in order, the smart contract creates an address in the external network (if necessary), to which the client transfers money. 5% of the amount received is sent to the agent's wallet and 95% is converted into the final currency of the transaction, after which the closing documents of the transaction are published and available for all sides to review, download, etc. Upon receipt of the "Closing Documents", the transaction is considered complete, Side B receives the NFT token for the apartment and the apartment disappears from the sales list. ### Use case #4 - freelance contract with the man in the middle Side A orders the service, Side B agrees to provide it, specifying the task, the implementation period, and the agreed-upon motivation amount, and Side A and B enter into a model contract on Site C with payment in one of the currencies, coins, or tokens available in the YAR protocol. This contract specifies the compensation for Site C, the task schedule, task performance facilitation, reporting periods, the expected outcome of the task, payment terms, and dispute resolution terms - with or without an escrow account. Side A and B agree to the terms of the contract, and Side A transfers the funds for the contract, whereupon Side B agrees to begin the task and to contractually report the interim results of its work at specified intervals. When the contract has been satisfactorily fulfilled, Side B receives compensation in the desired currency, Site C receives its commission, and Side A receives the result of the work and the transfer of intellectual rights to the result. At the same time, Site C through the API requests publication of the contract on the YARchain network via the API and processes the result of its work via GET and POST. Everything else is automated via the YAR. If you need to share files, the download and transfer are handled through a contract by connecting FileCoin or a similar service to the contract. # $YAR Utilization **1. Governance** [Become part of the YAR Validator Network and get voting power to participate in decentralized decision-making in YAR DAO.](https://docs.yarchain.org/whitepaper/project-mechanics/voting-in-yar-dao) **2. Proof of Stake** Stake $YAR to increase the YAR Validator Network and earn. **3. Payment & Trading** [Used to pay for transaction fees. $YAR can be moved between different networks free of charge](https://docs.yarchain.org/whitepaper/project-mechanics/transaction-fee-and-cross-chain-calls-discount#blockchain-2-blockchain-transactions). **4. Boost efficiency of capital** Stake $YAR in DAO to boost capital efficiency as a liquidity provider. **5. Yield Farming** Add liquidity in cross-chain pools and get rewards in $YAR tokens. **6. Discounts** [Cut the cost of cross-chain calls, exchange fees, and smart contract deployment.](https://docs.yarchain.org/whitepaper/project-mechanics/transaction-fee-and-cross-chain-calls-discount#blockchain-over_the_yar-based_dapp-blockchain-transaction) # Transaction fee and cross-chain calls discount YAR's target audience is DeFi, DEX, DAO, and Web3 projects that provide service in the B2C and B2B market. $YAR as a coin may be interesting for the mass market following the next 3 cases. {% hint style="info" %} The user can withdraw any assets from any blockchain to any including the native blockchain at any time. All assets are always backed 1-by-1 with circulation amounts. {% endhint %} ### Blockchain-2-Blockchain transactions #### Token transferring without external liquidity Token without external liquidity Every time the user makes a cross-chain transaction pays a Transaction Fee in the Domestic Blockchain (TFDB[^1]), a Transaction Fee in the Target Blockchain and YARchain (TFTB[^2]), and a YAR's bridge reward that equals 3% from TFTB[^2] (YBR[^3]). So each time before making the cross-chain transaction of the transferred token, YAR asks the user to pay TFTB[^2] and YBR[^3], and after token will be sent to the target blockchain. TFTB[^2] and YBR[^3] pay in coins of the domestic blockchain (ETH for Ethereum network, MATIC for Polygon, etc). So the user pays TFDB[^1] twice. In the next step, the bridge takes TFTB[^2] and YBR[^3] holds TFTB[^2] for the next transaction fee-paying and sends a request to YARchain to mint YBR[^3] amount as an erc20 token, buy $YAR on the YAR DEX, and burn it.
#### Token with external liquidity When the user sends a token with external liquidity, YAR offers to pay TFTB[^2] and YBR[^3] inside the transferred amount. In the next step, the bridge takes TFTB[^2] and YBR[^3] in transferred tokens and sends a request to YARchain to mint TFTB[^2] and YBR[^3] amount as an erc20 token, buy $YAR on the YAR DEX, and burn it. So the user pays TFDB[^1] once.
{% hint style="info" %} Rest assured that the current model guarantees both short and long-term liquidity of $YAR, and effectively mitigates the inflationary burden of new coins received by validators as rewards. {% endhint %} ### Blockchain-2-YARchain transactions Transferring coins and tokens inside the YARchain is always free for the user. The user pays only TFDB[^1].
### Blockchain-over\_the\_YAR-based\_DAPP-Blockchain transactions YAR offers to cut cross-chain transaction fee costs to zero for DAPPs that will be deploying in YARchain. **There are three cases:** #### Case #1: Pay TFTB[^2] for your user When DAPP's balance is more than 1,000 YAR, DAPP can offer the user free cross-chain transaction. In that case, DAPP pays TFTB[^2], not the user. It is a convenient way for users because they make only one transaction - sending assets to your service. {% hint style="info" %} Applicable for [Blockchain-2-Blockchain transactions](#blockchain-2-blockchain-transactions) {% endhint %} #### Case #2: YBR[^3] is free When DAPP's balance is more than 10'000 YAR, DAPP can cut up to 50% of cross-chain costs. {% hint style="info" %} Applicable for [Blockchain-2-Blockchain transactions](#blockchain-2-blockchain-transactions) {% endhint %} #### Case #3: TFTB[^2] is free When DAPP's balance is more than 100'000 YAR, DAPP pays nothing for cross-chain transactions. It is the biggest opportunity for to transactions cut spending for multi-chain DEX, payment services, NFT marketplaces, gaming platforms, arbitrating platforms, etc. {% hint style="info" %} Applicable for [Blockchain-2-Blockchain transactions](#blockchain-2-blockchain-transactions) {% endhint %}
{% hint style="info" %} An increase in DAPPs will boost coins held on YARchain-based smart contracts and demand for the coin. {% endhint %} [^1]: Transaction Fee in the Domestic Blockchain [^2]: Transaction Fee in the Target Blockchain and YARchain [^3]: YAR Brigde Reward # Conclusion YAR project solves one of the most significant problems of the crypto market - the liquidity migration between blockchains. An effective mechanism for organizing communication between any blockchains has been developed, and the system is easily scalable, allowing the connection of new modules and the expansion of functionality. # LEGAL DISCLAIMER ### Important Notice PLEASE READ THIS ENTIRE SECTION AND DON'T ACT UNTIL YOU'VE COMPLETED IT. THIS WHITE PAPER CONTAINS A SUMMARY OF THE SWACE BUSINESS MODEL, AND TECHNOLOGY, AND A BRIEF INTRODUCTION TO THE PRINCIPLES OF CHILDREN'S AID TOKENS. ### Purpose This whitepaper is intended to provide an overview of the YAR project and the YAR coin. The project described in this whitepaper is still under development and will be updated regularly, including technical features, token behavior models, and other functionality. The YAR team has the right to change, add, or remove information in this document at any time. ### Regulatory status is not assured in all jurisdictions YAR strives to comply with all applicable laws and regulations and to obtain the necessary licenses and permits in key markets. This means that the development and launch of all features of the YAR initiative described in this whitepaper cannot be guaranteed in terms of time. Regulatory licenses and/or permits may be required in some jurisdictions where relevant business is conducted. There's no guarantee or assurance that such licenses or approvals will be obtained within any particular time frame or at all. This means that the YAR Platform and other aspects of the proposed YAR may not be available in some or all markets. This could require a restructuring of the ecosystem and/or its complete or partial unavailability. In addition, the development of the platform is intended to occur in multiple phases rather than in one step. At various stages of development, the Platform may rely on relationships with third-party companies that have acquired licenses. If these companies are no longer legally licensed in their respective jurisdictions, the ability of the YAR Platform to work with this party, including its services and activities, would be impaired.