Vibly’s Final Missing Piece: A Non-Liquidation Stablecoin and 0-Fee Payment Network Based on VIB/DOT

Ecosystem
1

We have made the final adjustment to Vibly. From this point on, the core mechanism of the complete Vibly network is in place. The final missing piece, and also the most important part of Vibly, is a type of stablecoin known as a non-liquidation stablecoin. We assume that you already have a basic understanding of this concept, so here we only briefly summarize its core mechanism and characteristics:

  1. Based on the current price p, the system sets a risk boundary S, and VIB is split at S into a stable side P_S and a risk side N_S.

  2. You can merge P_S and N_S back into one VIB at any time:

VIB = P_S + N_S

  1. P_S gives up upside returns and becomes a stable asset. N_S is the risk side: it bears the downside protection risk of P_S and receives the remaining upside returns of the underlying asset. Therefore, it has nonlinear return characteristics similar to a leveraged long position or an option.

  2. The wrapper packages different P_S assets and eventually forms the stable VUSD.

  3. VUSD is not an accounting stablecoin. It is a value-stable coin anchored to the stable asset P_S.

  4. A fall in the VIB price does not trigger liquidation. N_S is the first to take losses, until the price falls below S and N_S goes to zero. When the price approaches S, P_S will trade at a discount. Only when the price falls below S, or when the risk buffer is exhausted, will P_S / VUSD suffer actual losses.

  5. Even if the price remains above S, discount risk still exists. The closer the real price is to S, the higher the discount, which causes drift in VUSD.

  6. Maturity-based designs introduce a settlement time M, with assets represented as P_{S,M} and N_{S,M}. This creates maturity settlement, oracle resolve, rolling management, asset fragmentation, and liquidity fragmentation problems. In addition, when the price is close to S and settlement is near, P_{S,M} will show stronger settlement sensitivity.

Basic Principle

Looking back at the design of the Vibly network, it is essentially a massive nested loop engine that can coordinate thousands of Agents running over long periods of time. The network decomposes a large vision or long-term goal into smaller strategies, and then decomposes them again until they become Tasks that can actually be executed at the current moment. This is similar to a large company breaking down a vision into strategies, then into annual plans, monthly plans, and finally execution.

A basic Loop contains the complete process from observation to review, all carried out by Agents, with humans requested when necessary. At fixed time intervals, the system calls observers to start a loop. This is called a Slot. The current testnet setting is 30 minutes. After reading the current state information, the observer formulates the Tasks for the next cycle. Observation itself is also a special, system-level Task. Other Agents can claim Tasks, complete them within the agreed time, submit results for evaluation, and receive rewards.

Unlike staking rewards, Tasks have floating but estimable costs and durations. It is more reasonable to use a stablecoin for pricing and settlement, so as to avoid the coordination complexity caused by using the system currency VIB. Therefore, the Vibly network has endogenous demand for a stablecoin.

The lifecycle of a Task spans multiple cycles. From the moment it is formally published, it includes at least three cycles: claiming and execution, review, and challenge. Especially in later stages, as task complexity increases, a single Task may need to run for several days. After commercialization, production, logistics, and other longer cycles may also be involved. This introduces a large amount of unsettled task funds into the system, forming a task settlement float similar to accounts receivable. For convenience, we will refer to it as “accounts receivable” below. At the start of a Task, the system locks VIB equal to the reward value and issues VUSD against it. We can briefly formalize this as follows:

The average Task lifecycle satisfies L ≥ 3. When a Task is published, the system locks VIB equal to the reward face value and issues VUSD according to a senior ratio η. If the total reward value of newly created Tasks in each cycle is R, then in steady state, active task accounts receivable is approximately LR, and the supported VUSD issuance is ηLR. After deducting the settlement payment R due in the current cycle, the theoretical VUSD float of the system is:

Float = R(ηL - 1)

When η = 50% and L ≥ 3:

Float ≥ 1/2 R

Therefore, the longer the Task lifecycle and the higher the unit price of a Task, the larger the accounts receivable formed by locked task rewards inside the system, and the larger the VUSD circulation space that can be supported. This is only a steady-state approximation. It does not mean that the system can unconditionally release the entire float. The actual circulating amount also needs to deduct risk reserves, redemption reserves, failed-task reserves, and price volatility buffers.

Based on this, Vibly forms a special system stablecoin by binding accounts receivable. Users do not need to actively split VIB themselves. However, it should be noted that the VIB used to generate VUSD is not created out of thin air. It mainly comes from two sources:

  1. System projects: projects such as VibMath bind LLM computing power and satisfy the market’s demand for stablecoins. This is why we can still launch the stablecoin system even under the condition that only VibMath is running. However, the complete stablecoin system should still be launched gradually under the premise of strict mint caps, risk reserves, N-side underwriting, and a DOT/VIB basket of assets.

  2. Ecosystem projects: Vibly is designed as a permissionless network. Anyone can create and join organizations and projects, and issue their own Token. After meeting requirements for liquidity, price sources, and risk parameters, third-party Tokens can be converted through restricted paths into VIB / DOT / whitelisted assets, and further participate in VUSD generation.

Implementation

Features

  • Automatic rebalancing: We synthesize the final user-facing VUSD through the wrapper, and naturally implement rebalancing within Vibly’s existing Loop.

  • Batch auction: After the system locks the underlying assets, it atomically generates P_S and N_S. The risk side N_S is released to risk underwriters through batch auctions. Only after N_S is successfully sold can the corresponding P_S enter the VUSD wrapper and support new VUSD issuance. If the N_S auction fails, the system stops issuing new VUSD and falls back to VIB / DOT / whitelisted stablecoin payments.

  • Basket assets: To mitigate VIB price volatility and task volatility, the system introduces DOT and supports the generation of VUSD from a basket of assets consisting of VIB / DOT / reserve.

  • Market simulation testing: We use Vibly’s own capabilities to call thousands of Agents with different personalities and investment styles, simulating market reactions and VUSD changes under various extreme conditions in a test environment, so as to discover risks in advance.

Optional

  • Adaptive S: S is not necessarily better when it is lower. If S is set too low, it will undoubtedly bring a safer stablecoin with lower drift, but it will also weaken the value of the option itself, causing users to prefer other option products such as those on CEXs and reducing demand for P_S. Conversely, if S is set too high, the system will face higher risk and higher drift. Nor can we use a fixed ratio to calculate an appropriate S, because it changes with market expectations. We can design an adaptive S that is relatively slow to respond to upward price movement and highly sensitive to downward price movement, allowing the system to better balance efficiency and safety. However, this would upgrade the oracle from a simple deterministic signal input into a risk model input, creating another attack vector and potentially introducing market manipulation risks.

Non-Goals

  • Two-sided market: A two-sided market can largely alleviate volatility on the demand side of P_S, but it does not improve depth. At the same time, a two-sided market may itself become the problem. Therefore, we will not adopt a two-sided market design.

User Strategy

Stablecoins are one of the clearest, most durable, and most demand-driven markets in the crypto industry. This market has been validated for many years, and user demand is highly clear: users need a stable, low-cost, fast, and easily transferable on-chain settlement asset. In a stablecoin payment network, low fees are the starting point of the user growth flywheel. Users first choose the network with the lowest cost and smoothest experience. This brings gradual user growth, after which more wallets, exchanges, merchants, and services begin to adapt. Once channels adapt, the user’s complete experience improves further, eventually forming stronger network effects.

Vibly naturally has the conditions to provide a low-fee payment experience. Stablecoins are Vibly’s underlying payment infrastructure, not its core profit source. Therefore, Vibly can optimize payment fees as a growth cost and system friction.

The reputation system further strengthens this capability. Vibly already has a continuous reputation evaluation mechanism for Agents. Combined with the identity system, this reputation mechanism can be extended to human users, organizations, and project teams.

This allows Vibly to provide a differentiated stablecoin payment experience: for trusted Agents, trusted users, and trusted organizations, the system can provide 0-fee VUSD payments within certain limits and frequencies, and extend this to whitelisted stablecoin payments such as USDT and USDC. We can further provide superlinear free quotas for high-reputation identities, and support delegated transactions through mechanisms similar to account abstraction, thereby offering near-free payment costs to other users without reputation. Since the reputation system adopts a sliding-window design, this will not damage the security of the reputation system.

Existing stablecoin networks mainly serve transfers between people, between people and exchanges, and between people and merchants. Vibly’s most natural payment scenario is machine payment, which will become the differentiated scenario and long-term moat of the Vibly payment network.

Therefore, Vibly’s user strategy can be summarized as follows: use stablecoin demand as the system’s value foundation and market entry point; use low fees as the starting point of growth; use the reputation system to support a 0-fee experience; use the identity system to expand trusted payment objects; and use machine payment to form a differentiated scenario. The first step is to make VUSD the most natural, lowest-friction, and most suitable payment asset for Agent collaboration within the Vibly network, while continuously optimizing experience and accumulating users, liquidity, and channel support.

Governance

Stablecoins can easily become highly reflexive systems. Certain hard-to-detect mechanism design errors or parameter errors may be amplified by market expectations and form a death spiral. Vibly needs a risk governance framework for complex financial systems. We will deeply bind Vibly to the Polkadot governance mechanism, mainly for three reasons:

  • Trusted public governance foundation: VUSD issuance, risk parameters, asset whitelists, oracles, auction mechanisms, and emergency handling all need to be transparent, traceable, and open to questioning.

  • Ecosystem-level support: VUSD depends on DOT liquidity, Asset Hub, DeFi infrastructure, wallets, exchanges, oracles, cross-chain assets, and other ecosystem-level support.

  • Governance constraints: Relaxing risk parameters in order to maintain growth is a common dangerous behavior in finance, and it must be placed under governance constraints.

For the purity of governance, the ArcheLabs team will not reserve any VIB. Treasury governance will serve as the core coordination mechanism for Vibly’s long-term development. In addition, compared with Polkadot, Vibly has a more specific application goal, so it requires a small amount of differentiated adjustment to OpenGov. Governance is another larger topic, and we will explain it in detail later.

Plan

We will complete the following steps:

  1. Complete the full PoC of the stablecoin described above.

  2. Tokenomics: At present, the rough plan is that most VIB will be retained in the treasury, while the rest will be airdropped to DOT holders and early Vibly supporters. The team will reserve no allocation.

  3. Complete the governance version of Vibly-chain: it will only include basic economic and governance capabilities. We will make limited modifications to OpenGov and provide detailed reasons.

  4. Mainnet: Vibly mainnet will launch on Polkadot and start governance to coordinate subsequent development and operations.

  5. Rebuild the protocol and mainnet Vibly-chain: this part requires auditing the previous design and implementation. The core parts should be manually coded, so it will likely proceed slowly.

After completing the final step, we will also have completed the early full implementation of Vibly. We will then deliver a complete, production-ready Vibly to the community, after which the community will continue advancing Vibly under the governance framework.

We will also continue, as always, to focus on low-level technology development, and continue exploring and implementing other applications that are more interesting and valuable to the community.

By the way, the forum does not seem to support formula syntax, so I have used plain-text notation instead.