Euclidprotocol
Euclidprotocol: from vouchers to native tokens
Euclid Protocol uses vouchers to represent asset balances on its Virtual Settlement Layer (VSL), with 1:1 backing in native-chain escrow. Redemption uses those balances to request the corresponding underlying tokens on one or more supported destination chains. Keeping a balance as vouchers allows further activity inside Euclid without releasing the underlying assets on every internal operation.
· updatedWhere the voucher balance lives
The VSL hub records virtual balances for users and Virtual Liquidity Pools (VLPs). Its
virtual_balance
contract indexes balances by
(chain_uid, address, token_id)
, so the chain context, address, and token identifier all belong to the balance record.
When assets enter Euclid from another chain, escrow balances are updated and vouchers represent the deposited amount for the sender. Only the router can mint or burn voucher balances. The 1:1 relationship concerns units of the underlying asset; the asset retains its market-price risk.
Using vouchers before redemption
Internal swaps and liquidity operations use voucher balances. Adding liquidity lets a VLP spend a user's vouchers through an approval; swaps and liquidity removals use voucher transfers for the internal movement of value. Vouchers can also be transferred between Euclid users. These internal movements do not require physical assets to move across chains at every routing hop.
A voucher is a distinct token type within Euclid. It has no conventional on-chain denomination or standard balance query and uses the hub's virtual-balance system. External applications need to integrate Euclid's liquidity layer to use vouchers directly. Redemption provides the underlying asset, whose compatibility with another application depends on that application's supported assets and network.
Requesting the underlying tokens
Voucher redemption uses
WithdrawVoucher
. The router checks the user's voucher balance through
GetBalance
, then releases escrowed assets to the requested destination chain or chains. The requested release still needs the corresponding asset in escrow on its destination.
A voucher can represent an asset on a Euclid-connected chain where that asset is not native. Keeping the voucher there and redeeming the underlying asset on a selected chain are separate choices. The virtual balance records entitlement to the asset; it does not establish that native tokens have already arrived at a destination.
Dividing a redemption between destinations
How much can be allocated to a second destination after choosing the first? Consider a hypothetical redemption of 735 voucher units representing one asset, with 285 underlying asset units allocated to hypothetical destination A. Assume hypothetical destinations A and B are both supported and each has enough escrow liquidity for its allocation.
Destination B's requested allocation is
735 - 285 = 450
underlying asset units. The two destinations divide the single 735-unit redemption, with 285 units allocated to A and 450 to B.
With the total held fixed, increasing A's allocation reduces B's allocation by the same amount. Each allocation must remain nonnegative and within the total. These are requested allocations before any applicable costs; the calculation does not determine net receipts or completion time.
The separate Euclid Launch balance
Euclid Protocol's tutorial How To Use Euclid Launch , published January 2, 2026, describes trading with vouchers deposited into a Launch account. Its Portfolio flow requires the vouchers to be in the same wallet used to sign into Launch, followed by a deposit on the selected chain and signed transactions awaiting confirmation.
In that documented flow, Launch accepts EVM wallet connections. Cosmos-based voucher deposits use Euclid Swap. These interface conditions apply to the Launch flow and do not define the wallet support of the entire protocol.
The tutorial's gasless-trading claim concerns trading with deposited vouchers. Its deposit instructions still require transaction signatures and confirmation. The trading claim alone does not specify deposit or native-token withdrawal costs.
Backing and transaction risk
Euclid's Terms of Service decline settlement guarantees for token transactions and describe risks from software failures, liquidity shortages, and service interruptions. They also state confirmed blockchain transactions are irreversible. Voucher backing and a valid balance therefore do not amount to a promise that a particular native-token release will complete.
