Business processes need more than smart contracts.
Your process should be digital, automatable and auditable. But in the real world, sensitive data, approvals, APIs, cutoffs and edge cases break the happy path. XGR adds the missing process layer: validate inputs, execute the next step, and log the decision — without exposing plaintext business data.
A real process is more than a single contract call: validate the current step, decide what is valid, execute the next action, and keep the outcome explainable.
- private business data can stay encrypted
- outcomes become explainable
- API outputs can be validated, and the decision result is logged on-chain
Why XGR stands out
A modern chain for real-world automation — fast enough for user-facing workflows, strict enough for auditable process execution, and familiar enough for builders to adopt quickly.
How XDaLa works (Builder quickstart)
This is the smallest builder flow — not the full product story. In practical terms: define a rule, store it in XRC-137, publish an XRC-729 orchestration (OSTC), then start a session.
The rule logic is deterministic. External API calls are not. XDaLa validates returned data, evaluates the rule, and records the decision result on-chain.
1. Define the rule
Write an XRC-137 JSON rule that says which inputs are expected and what should happen when the result is valid or invalid.
Minimal XRC-137 example
{
"payload": {
"Amount": { "type": "int64" }
},
"rules": [
"[Amount] > 0"
],
"onValid": {
"payload": {
"result": "ok",
"amount": "[Amount]"
}
},
"onInvalid": {
"payload": {
"result": "invalid",
"reason": "Amount must be > 0"
}
}
}2. Put the rule on-chain
Deploy an XRC-137 contract and store the rule JSON in it. That contract becomes the on-chain container for one rule document.
Canonical interface shape
interface IXRC137 {
function getRule() external view returns (string memory);
function setRule(string calldata jsonOrBlob, bytes32 rid, string calldata suite) external;
function isEncrypted() external view returns (bool);
function getEncrypted() external view returns (bytes32 rid, string memory suite);
}
After deployment, call setRule(ruleJson, 0x00..00, "") to store plain JSON, then verify via
getRule().
3. Publish the orchestration
Publish an XRC-729 orchestration (OSTC) that maps a process step such as S1 to the rule contract and defines the valid and invalid next paths.
Minimal orchestration example
{
"id": "hello_xdala",
"structure": {
"S1": {
"rule": "0x<your_XRC137_rule_contract>",
"onValid": {},
"onInvalid": {}
}
}
}
Your client typically pins an ostcHash (keccak256 of the UTF-8 JSON) for auditability and later binds that hash into the signed session permit.
4. Start the session
Fetch xgr_getCoreAddrs and xgr_getNextProcessId, build and sign an EIP-712 SessionPermit,
then call xgr_validateDataTransfer to submit the current step for validation.
Minimal RPC call shape
{
"jsonrpc": "2.0",
"id": 1,
"method": "xgr_validateDataTransfer",
"params": [
{
"stepId": "S1",
"payload": { "Amount": 42 },
"permit": { "...": "SessionPermit (EIP-712) + signature" },
"orchestration": "0x<your_XRC729_contract>"
}
]
}
The signed SessionPermit binds the session to values such as ostcId, ostcHash, sessionId,
maxTotalGas and expiry. XDaLa then evaluates the submitted data against the rule, selects onValid
or onInvalid, and the orchestration determines the next path and resulting actions.
Want the full contract interfaces, OSTC schema, typed-data definitions and RPC details? Jump into Docs.
What you can build
XDaLa is strongest where a normal smart contract is too static: approvals, exceptions, policy checks, multi-step execution and auditable handoffs.
Movement with guardrails
Enforce roles, limits, approvals, or whitelists before value moves. Make exceptions explicit and auditable.
Who can move value — and under which conditions?From events to execution
Trigger multi-step actions on schedules or external facts. Spawn sub-flows and loop with safeguards.
When a rule evaluates true, the process can continue.Confidence without exposure
Keep sensitive details private while producing verifiable evidence for decisions and outcomes.
Reveal the outcome — not the plaintext.Multi-party, accountable
Coordinate teams and systems with tamper-evident trails and clear hand-offs between steps.
Every step has an owner, a reason and a trace.Concrete examples
A few patterns teams can ship with XDaLa on XGR — adaptable to your rules, data model and process design.
Structured payments, policy-first
Validate structured payment data, enforce limits and approvals, then settle — with verifiable evidence, without exposing sensitive details.
Act on real-world facts
Consume signed feeds such as prices, FX, weather, IoT oracles or attestations and trigger actions when thresholds or conditions are met.
From order to settlement
Coordinate order → fulfillment → settlement with milestone-based releases, exceptions, and approvals — all auditable.
Checks before action
Run policy checks before transfers or contract calls. Keep private inputs private while keeping the proof on-chain.
Streams, splits, and caps
Automate multi-sig approvals, streaming payouts, vesting schedules, and budget caps tied to events or time.
Trust with clear rules
Hold funds in escrow, define dispute windows, and resolve outcomes automatically with a transparent audit trail.
Built in Europe. Built for builders.
Serious infrastructure for real-world automation: privacy-aware, implementation-focused and designed to stay compatible with how builders already work.
From the heart of Europe
Created by XGR.Network GmbH, we champion privacy, security, and responsible innovation — with European quality at our core. Impact features are supported as optional primitives, not as a blanket promise.
Builder-first experience
Clean APIs, familiar tooling, fast confirmations. Go from idea to production without reinventing your stack.
Auditable by design
Keep the important evidence on-chain so teams, partners, and auditors can verify outcomes without friction.