Intent Matching 1.0Intent撮合1.0

0. Program objectives (one sentence)

Without changing EVM, use off-chain MoveVM for intent matching and structure management.

Use Flux as gas and Power as the life limit, and only do one thing:

Under the correct structural dependency D, safely help users transfer assets/tasks to the target.

1. Core components

1.1 Object & ID

• Everything is abstracted into Object: users, agents, projects, fund pools, models, tasks...

1.2 Dependence Figure D (Structural Truth)

• Maintain a graph: D true(X, Y) ∈ [-1, 1] means “the strength of X’s structural dependence on Y”

1.3 Power (maximum life)

• Maximum of 21,000,000 Power per ID per lifetime
• Off-chain MoveVM maintenance PowerAccount: Unlocked / Consumed
• Purpose: Sufficient unlocked Power is required before sending Intent/receiving orders.
• Structural damage/burning Power when doing evil
• H (alignment) is high → unlocking power is more per cycle; H is low → unlocking is reduced or even stopped

Power = "life energy level + trust limit" of this ID in the system.

1.4 Flux (Gas)

• Flux is only used as execution cost (gas) and can only be accounted within MoveVM: Send Intent: deduct a small amount of Flux
• Verification/matching/settlement calculation: consumes Flux
• When PoCW proves real work: Reward Flux
• Garbage Intent / Violation: Burning Flux

1.5 Intent (minimalist structure)

Intent {

user: ID // Who sent it

transfer: (Object, amount) // Things to "transfer" (funds/tasks/permissions...)

target: Object // Who to transfer to / Which object to act on

cond: CondID // Under what conditions execution is allowed (verifiable)

goal: GoalFn // The numerical goal you want to achieve (such as ≥5 USD equivalent to BTC)

d min: float // Minimum structural consistency requirement, for example 0.3

expiry: time // Expiration time

nonce: uint // Anti-replay

}

Mental model:

Intent = Transfer + Cond + Goal + D min

= Under certain conditions, move an object to the target according to structural constraints D min, and achieve a verifiable result.

2. Architecture layering

2.1 EVM layer (Assets & Settlement)

• All real assets on EVM/L2: USDC / ETH / WBTC / NFT…
• Deploy a Settlement contract: Receive the SettlementAction packaged by MoveVM under the chain
• Verify signature/authority
• Call transferFrom / DEX / other protocols
• Keep your funds safe
• Users only do two things in EVM: approve assets to Settlement
• Use wallet to perform EIP-712 offline signature on Intent

2.2 Off-chain MoveVM layer (Intent matching + structural governance)

A set of Move modules in MoveVM maintain status:

• IntentPool: Unfinished Intent
• Dependency Graph: D true graph
• PowerAccount / FluxAccount / HAccount
• Orderbook: Intent order book by (asset, target) market
• PoCW: Record the workload of each Worker

MoveVM is responsible for:

1. Signature verification (off-chain)
2. Deduct the user’s Power/Flux (the cost of opening an Intent)
3. Check D true(transfer.object, target) ≥ d min
4. Verify the legality and verifiability of cond and goal
5. Place the Intent into the order book corresponding to the (asset→target) market
6. Match Need / Offer Intent, determine counterparty, execution path, quantity
7. Generate SettlementAction (what should be executed on the EVM)
8. Send Flux to Worker according to PoCW, update H and future Power unlocking rate

3. Standard pipeline example

Take example Intent:

“Exchange 3 USDC for at least 5 USD worth of BTC with <1% slippage.”

Step 0: EVM side preparation

• User on EVM: approve(USDC, Settlement, 3e6)

Intent {

User: 0xUser

transfer: (USDC, 3e6)

Target: BTCPoolObject

Condition: Slippage less than 1%

goal: value in USD >= 5e6

d min: 0.3

Expiry Time: T

Random Number: N

}

Step 1: MoveVM reception & verification

1. Verification
2. Deduct a small amount from PowerAccount[user] (e.g. 10 Power)
3. Deduct one Flux (e.g., 1 Flux) from FluxAccount[user]
4. Check DependenceGraph: D true(USDC, BTCPoolObject) ≥ 0.3
5. Otherwise, reject the Intent and burn part of the Flux.
6. Pass → Put the Intent into the (USDC→BTC) market order book

Step 2: MoveVM Matching

1. Find an opponent or liquidity offer that satisfies cond + goal
2. Calculate the execution path (such as the Swap path of Uniswap on EVM)
3. Determine the BTC that can reach value ≥ 5 USD at the current price
4. Record which Worker completed the matching (PoCW)

Generate settlement action:

Settlement Action {

Chain: Ethereum,

Source: 0xUser,

Asset: USDC,

Quantity: 3e6,

Call: {

Target: UniswapRouter,

Data: swapExactTokensForTokens(

3e6,

Minimum output = $5 worth of BTC,

path = [USDC, WETH, WBTC]

)

}

}

Step 3: EVM Settlement Execution

• Some matcher will package the SettlementAction into a transaction: Settlement.execute(action)
• In the contract: Check: user’s allowance for USDC is sufficient
• The caller/executor is whitelisted/multi-signature approved/or proven through post-rollup

Step 4: Accounting after MoveVM settlement

• Settlement successful: Mark the Intent as completed
• Send Flux to the completed Worker (based on PoCW + H)
• User's behavior structure is aligned this time → H(user) increases a little → Power is unlocked faster in the next cycle

4. Three lines of "general review" copywriting (can be spoken directly to external parties)

1. Intent is minimalist: Intent = Transfer + Cond + Goal + D min, any complex operation becomes "under certain conditions, transfer an object to the target according to structural constraints and achieve verifiable results."
2. Flux & Power: Flux is the gas for execution/verification/matching, PoCW generates Flux, and violations will burn Flux; Power is the upper limit of the life energy level of each ID. The higher the H, the faster it is unlocked, and the more misaligned it is, the more locked it is.
3. MoveVM × EVM division of labor: Off-chain MoveVM serves as the brain: Intent matching + structural governance; EVM serves as the money bag: asset security settlement; both parties are connected through SettlementAction.

This is a set of converged overall design plan v0,

It can be directly thrown to technology/products for decomposition:

• Move side: What modules are needed
• EVM side: Settlement contract interface
• Front-end: Intent structure & signature process.