SON validates meaning before execution. Raw intent is scored by deterministic validator engines, converted into a consensus command, and handed to contracts, solvers, vaults, bridges, or review gates.
Oracles report facts. SON validates intent.
A price oracle answers: what is the asset worth? SON answers: which action coheres with the stated intent, constraints, and risk posture? The result is not prose. It is a ranked command surface: winner, score, gap, and escalation condition.
SON is not another exchange, wallet, bridge, or solver. It is a semantic validation layer above execution infrastructure. Validators run local deterministic engines and converge on the command that best matches the broadcast intent.
Execution should not begin until meaning is resolved. SON compares validator score surfaces, confirms the winning command, verifies the gap, and escalates when semantic consensus is too narrow or divergent.
SON is spendable command credit. Users buy SON, spend it per validated command, and the protocol burns or routes the fee. The buyer sees a simple price: one cent per semantic command. The token is plumbing, not the headline.
The user does not calculate token units. They buy balance, route commands, and spend one cent of SON per resolved semantic decision.
SON behaves like API credit. Wallets, dApps, solvers, and enterprises pre-buy balance and spend it as commands are resolved.
Pricing is published in USD, not token units. If SON trades higher, fewer tokens are consumed. The command still costs one cent.
Every validated command consumes SON. High-frequency integrations burn through balance quickly and refill before execution paths run dry.
Low-frequency users leave prepaid balance in the protocol. High-frequency users create recurring command demand through wallet, dApp, and solver integrations.
500 commands for testing wallets, demos, and small dApps.
2,000 commands. The default developer balance.
10,000 commands for active apps and solver prototypes.
100,000 commands for production routing and high-frequency use.
Committed command volume, audit surfaces, and private policy controls.
Solvers optimize execution. SON validates the command. That distinction matters: a system cannot optimize a route until it understands what the user actually asked to preserve, avoid, or accomplish.
Wallet, dApp, enterprise system, or contract submits raw intent and candidate command surface.
Validators run local deterministic engines and produce coherence scores for each command.
Network accepts the winner only when score surfaces and gap metrics satisfy consensus rules.
Result routes to solver, bridge, vault, custody workflow, compliance lane, human review, or no-route safeguard.
Solvers compete over execution. SON validates the command before execution exists. It is the layer that says: this is the intended action, this is the score surface, this is the gap, and this is where the system must route next.