Layer 1: Intent Surface
The Intent Surface is VORT's interface between human intent and machine execution. This layer transforms user desires—expressed in natural language, structured data, or programmatic interfaces—into precise, machine-readable representations that agents can reason about and execute.
Natural Language Processing
VORT's Natural Language Processing (NLP) system enables users to express intents in conversational language, making the system accessible to non-technical users while maintaining the precision required for reliable execution.
Intent Parsing Architecture
The NLP system uses a multi-stage parsing pipeline that progressively refines understanding:
Stage 1: Tokenization and Segmentation
Input text is tokenized into words, phrases, and semantic units
The system identifies intent boundaries (where one intent ends and another begins)
Contextual markers (pronouns, references) are resolved to their referents
Stage 2: Semantic Role Labeling
The system identifies semantic roles: who is the actor, what is the action, what is the target, what are the constraints
For example, in "Rebalance my portfolio to 40% SOL", the system identifies:
Actor: "my" (the user)
Action: "Rebalance"
Target: "portfolio"
Goal: "40% SOL"
Stage 3: Intent Classification
The parsed structure is classified into intent types: swap, rebalance, yield optimization, risk management, etc.
Classification enables the system to apply type-specific parsing rules and validation logic
Stage 4: Parameter Extraction
Specific parameters are extracted: amounts, percentages, token symbols, constraints, preferences
The system handles ambiguity by applying context and user preferences
For example, "some SOL" might resolve to a specific amount based on the user's portfolio size and historical patterns
Stage 5: Constraint Inference
Implicit constraints are inferred from the intent and user context
For example, "rebalance quickly" might infer a preference for speed over cost optimization
User-defined policies are applied to add additional constraints
Handling Ambiguity
Natural language is inherently ambiguous. The NLP system uses multiple strategies to resolve ambiguity:
Contextual Disambiguation: The system maintains context from previous intents and user interactions. If a user says "do it again", the system understands what "it" refers to based on recent history.
User Preference Learning: The system learns user preferences over time. If a user consistently prefers certain protocols or execution strategies, these preferences inform ambiguity resolution.
Interactive Clarification: When ambiguity cannot be resolved automatically, the system may prompt the user for clarification. However, this is used sparingly to maintain the declarative, non-interactive nature of intent submission.
Default Policies: System-wide and user-specific default policies provide fallback values when parameters are ambiguous. For example, if slippage tolerance is not specified, a user's default slippage policy is applied.
Multi-Intent Parsing
Users can submit multiple intents in a single message. The NLP system identifies intent boundaries and parses each intent independently:
The system parses this as three distinct intents:
Portfolio rebalancing intent
Yield optimization intent
Risk management intent
Each intent is processed independently, though they may share context (e.g., all refer to the same user's portfolio).
Semantic Diffing
Semantic diffing is the process of comparing the current on-chain state with the desired end state to identify the execution gap—the set of actions required to transform current state into desired state.
State Representation
Before diffing can occur, both current and desired states must be represented in a common format. VORT uses a semantic state representation that abstracts away protocol-specific details:
Portfolio State: Represented as a set of token holdings with amounts and percentages
Position State: Represented as positions with leverage, collateral, and risk metrics
Yield State: Represented as allocations across yield sources with expected returns
This semantic representation enables the system to reason about state changes without understanding the underlying protocol mechanics.
Diffing Algorithm
The semantic diffing algorithm identifies the minimal set of actions required to transform current state into desired state:
Step 1: State Normalization
Both current and desired states are normalized to a common representation format
Protocol-specific details are abstracted away
Units are standardized (percentages, absolute amounts, etc.)
Step 2: Difference Calculation
The algorithm calculates differences for each state dimension:
Token holdings: differences in amounts and percentages
Position parameters: differences in leverage, collateral, etc.
Yield allocations: differences in protocol allocations
Risk metrics: differences in risk scores, health factors, etc.
Step 3: Action Inference
Differences are mapped to executable actions:
Token amount differences → swap actions
Position parameter differences → position adjustment actions
Allocation differences → reallocation actions
Risk metric differences → risk management actions
Step 4: Dependency Analysis
The algorithm identifies dependencies between actions
Some actions must occur before others (e.g., swap before deposit)
Some actions can occur in parallel
Dependency analysis enables optimal execution ordering
Step 5: Constraint Application
User constraints are applied to filter and modify inferred actions
Actions that violate constraints are rejected or modified
Alternative actions are proposed when constraints prevent direct execution
Handling Complex State Transitions
Some intents require complex state transitions that cannot be achieved through simple action sequences. The diffing algorithm handles these through:
Multi-Step Planning: Breaking complex transitions into sequences of simpler actions, with intermediate state validation at each step.
Alternative Path Exploration: When multiple paths exist to achieve the desired state, the algorithm explores alternatives and selects the optimal path based on cost, speed, and risk.
Partial Fulfillment: When full fulfillment is impossible (e.g., due to liquidity constraints), the algorithm identifies the closest achievable state and proposes partial fulfillment with user notification.
Policy Modules
Policy modules allow users to define guardrails that apply to all their intents, ensuring consistent behavior and risk management without requiring explicit specification in each intent.
Policy Types
VORT supports multiple policy types that govern different aspects of intent execution:
Risk Policies: Define risk tolerance and risk management rules
Execution Policies: Define execution preferences and constraints
Protocol Policies: Define preferences for specific protocols
Compliance Policies: Define regulatory and compliance constraints
Policy Hierarchy
Policies are organized in a hierarchy that determines precedence:
System Policies: Default policies defined by VORT that apply to all users (safety limits, protocol constraints, etc.)
User Default Policies: Policies defined by users that apply to all their intents unless overridden
Intent-Specific Policies: Policies attached to specific intents that override user defaults
Temporary Policies: Policies that apply for a limited time (e.g., "for the next hour, prioritize speed over cost")
When policies conflict, the hierarchy determines which policy takes precedence. More specific policies (intent-specific) override more general policies (user defaults).
Policy Validation
Before an intent is executed, all applicable policies are validated:
Compatibility Checking: The system verifies that the intent can be fulfilled while respecting all policies. If policies make fulfillment impossible, the intent is rejected with a detailed explanation.
Constraint Propagation: Policies add constraints to the intent execution. These constraints are propagated to agents, who must respect them in their execution plans.
Policy Override Requests: In exceptional cases, users can request policy overrides. These requests are logged and may require additional authentication or confirmation.
Dynamic Policy Updates
Policies can be updated dynamically, and changes apply to future intents:
Immediate Application: Policy updates apply immediately to new intents. Intents already in execution continue with the policies that were active when they were submitted.
Policy Versioning: The system maintains a version history of policy changes, enabling audit trails and rollback if needed.
A/B Testing: Users can define multiple policy sets and test them on different intents to evaluate their effectiveness.
Shared Context Vaults
Shared Context Vaults are centralized repositories that store all information related to an intent, ensuring consistent context across all agents and system components.
Vault Structure
Each Context Vault contains multiple sections:
Intent Metadata: Original intent submission, parsing results, validation status, timestamps, and lifecycle tracking information.
State Snapshots: Snapshots of relevant on-chain state at key points in the intent lifecycle (submission, execution start, execution completion).
Execution Plans: Agent execution plans, bid details, coalition agreements, and coordination protocols.
Execution Logs: Detailed logs of all actions taken during intent fulfillment, including transaction hashes, RPC calls, and agent decisions.
Proofs and Receipts: Cryptographic proofs, execution receipts, and verification results.
User Context: User preferences, historical patterns, portfolio context, and other information that informs intent understanding and execution.
Vault Access Control
Context Vaults implement fine-grained access control:
User Access: Users have full access to their own intent vaults, enabling them to inspect execution details and verify outcomes.
Agent Access: Agents have access to relevant sections of vaults for intents they are bidding on or executing. Access is scoped to minimize information leakage between competing agents.
Auditor Access: Auditors can access vaults (with user permission) to verify execution correctness and system integrity.
System Access: VORT system components have access to vault sections needed for their operations (parsing, validation, settlement, etc.).
Vault Propagation
Context information is propagated to agents through the vault system:
Intent Publication: When an intent is published, relevant vault information is made available to agents for bid preparation.
Execution Updates: During execution, agents update the vault with their actions, enabling other agents (in coalitions) to coordinate effectively.
State Synchronization: The vault maintains synchronized state information, ensuring all agents work with consistent, up-to-date data.
Event Broadcasting: Important vault updates (execution milestones, state changes, errors) are broadcast to relevant agents and system components.
Vault Persistence and Archival
Context Vaults are persisted for audit and analysis:
Active Storage: Vaults for active intents are stored in high-performance databases for fast access.
Archival Storage: Completed intent vaults are archived to long-term storage, maintaining full execution history.
Retention Policies: Vaults are retained according to user preferences and regulatory requirements. Users can configure retention periods and archival policies.
Query Interface: Archived vaults can be queried through VORT's API, enabling historical analysis and audit trails.
Privacy and Encryption
Sensitive information in Context Vaults is encrypted:
User Data Encryption: Personal information, portfolio details, and trading strategies are encrypted at rest and in transit.
Selective Disclosure: The vault system supports zero-knowledge proofs that enable verification without revealing sensitive details.
Agent Privacy: Agents' proprietary strategies and internal decision-making processes are not stored in vaults, maintaining competitive advantages.
Compliance: Vault encryption and access controls comply with relevant data protection regulations (GDPR, etc.).
Last updated