Unified Compute Language
One language for
intelligent & trustless
compute.
DEXA is a statically typed, deterministic language being built to target GPU kernels, native binaries, and contract VMs — without Python’s runtime overhead or Solidity’s security traps. The current prototype is a small, typechecked core and an interpreter that runs real programs today.
Targets
CPU · GPU · WASM · DX-VM
Domains
AI / ML · Smart Contracts · Secure Compute
Core values
Deterministic · Safe · Fast
// Nominal record + runtime checks
model Wallet {
owner: address
balance: int
}
fn credit(w: Wallet, amount: int) -> Wallet {
require(amount > 0, "amount must be positive");
return Wallet { owner: w.owner, balance: w.balance + amount };
}
fn main() -> int {
let w: Wallet = Wallet { owner: "addr:debug", balance: 0 };
let w2: Wallet = credit(w, 5);
print(w2);
require(w2.balance == 5, "bad balance");
return w2.balance;
}
// Future direction: tensors + contract subset
model Classifier {
fn forward(x: tensor<float,3x224x224>) -> tensor<float,10> { ... }
}
contract RewardPool {
asset<Token> pool
fn reward(user: address, score: int) { ... }
}
This block is intentionally labeled: it’s the goal, not the current surface.
Why DEXA exists
Today’s compute stack is split and fragile. AI runs on Python glued to native code and GPU toolchains. Smart contracts run on Solidity glued to VM semantics that are hard to reason about. Every layer adds risk, latency, and undefined behaviour. DEXA is an attempt to collapse that stack into one language and one set of deterministic semantics — starting with a small core you can actually execute and test.
AI / ML
High-level, compiled ML (goal)
Tensor-native types, graph lowering, and GPU codegen — planned on top of the deterministic core.
Design preview — not in the prototype yet.
Contracts
A safer contract subset (goal)
Asset-aware types, deterministic execution, and restricted semantics aimed at making common exploit classes harder to express.
Design preview — not in the prototype yet.
Runtime
Deterministic compute core (implemented)
A small, typechecked core with explicit semantics. Execution yields structured results (value + prints + trace + gas), not vague “it crashed” behaviour.
AI / ML without Python’s ceiling (design preview)
The goal: keep the expressiveness people like, but move it into a compiled, statically typed environment that can generate GPU kernels and deterministic graphs. This is not implemented yet — it’s where the core is headed.
- • Planned tensor<T, shape> types.
- • Planned graph lowering + optimisation passes.
- • Planned GPU backends (start small, expand later).
- • No interpreter glue in the end-state.
This section is intentionally labeled “design preview” to keep the site honest.
Example · Model definition
Design preview
model Encoder {
fn forward(x: tensor<float,3x256x256>) -> tensor<float,64x64x64> {
// planned tensor semantics
...
}
}
Example · Asset-aware contract
Design preview
contract Vault {
asset<Token> balance
fn withdraw(to: address, amount: Token) {
require(balance >= amount)
balance -= amount
transfer(to, amount)
}
}
Smart contracts with less foot-gun surface (design preview)
The claim is not “bugs are impossible.” The claim is: a restricted contract subset, combined with deterministic semantics and asset-aware typing, can make common failure modes harder to express and easier to audit.
- • Asset-aware types to push conservation rules into the compiler.
- • Deterministic execution model with predictable cost semantics.
- • Hooks for analysis/verification once the core is locked.
Architecture at a glance
DEXA compiles through a shared intermediate representation into multiple specialised backends. The same source is intended to target native binaries, GPUs, or deterministic virtual machines — once those backends exist.
Frontend
Language core
- Lexer & parser
- Static type checker
- Nominal record types
- Deterministic semantics
IR
DX-IR
- Locals, blocks, calls
- Control-flow
- Trace + gas accounting
- Execution as ProgramResult
Backends
Targets
- Interpreter (today)
- LLVM (planned)
- GPU kernels (planned)
- DX-VM (planned)
Roadmap
Phases matter because credibility matters. The public site calls out what is implemented vs what is planned.
Phase 0.x
Core (implemented)
- Lexer & parser
- Typechecker
- Nominal records + address
- DX-IR + interpreter + ProgramResult
Phase next
Tooling polish
- Diagnostics quality
- Collections (arrays/slices)
- CLI JSON output
- Minimal stdlib
Phase later
Backends
- LLVM backend
- Tensor semantics + GPU
- Contract subset + DX-VM
- Playground + ecosystem