Product engineering · 6 min read
The .sync runtime is an AIMB-X research concept. Before developers can rely on it, the model needs an explicit lifecycle that distinguishes local validation, network acceptance, deterministic execution, proof availability, finalization, and any cross-chain acknowledgement.
Specify states before interface language
A runtime state should describe what the protocol has established, not what an interface expects to happen. The same vocabulary should appear in specifications, node APIs, SDKs, reference applications, and test cases.
A transition is incomplete until its acceptance rule and failure behavior can be independently reproduced.
- Constructed
- Locally validated
- Submitted
- Accepted for execution
- Executed
- Finalized
- Proof available
- Rejected or expired
Make deterministic behavior visible
Developers need to know how calls are ordered, how resources are charged, which state is rolled back after failure, and whether nested calls can partially complete. Ambiguity at this layer becomes application-level inconsistency.
Reference traces and conformance tests can make the proposed semantics easier to challenge and improve.
Separate local and cross-chain completion
A .sync transaction can be final on AIMB-X while a related message remains unverified on another chain. Applications should represent these as different states instead of implying atomic completion across incompatible finality systems.
- Local execution result
- Local finality
- Proof generation
- Destination verification
- Destination execution or rejection
Treat performance as measured evidence
Execution architecture may be designed for high throughput, but specific TPS statements require a published workload, hardware profile, network topology, duration, failure conditions, and reproducible results. Until then, throughput is a research target rather than an achieved outcome.