Layered Architecture Overview

Overview. Identity and Reputation/Governance manage keys, attestations, scores, tiers, and parameters. Job/Escrow holds job specifications and escrow and interacts with Settlement for final pay/refund/slash and challenge resolution. Proof/Oracle lives off-chain: robots submit artifacts and oracles attest quality and verdicts that Settlement consumes. Posters submit jobs to Job/Escrow; robots accept, reveal, and submit; oracles attest; watchers may challenge; Settlement finalizes outcomes.

Identity Layer

Each robot has a DID [4] mapped to an Ethereum address. DID documents include:

• Public keys for transactions and telemetry signatures

• Firmware and stack hashes

• Optional TEE/TPM quotes [5], including PCR values and certificate chains

Key design:

• Session keys: Per-job ephemeral keys derived from device keys; rotated and discarded post-settlement.

• Binding: The session public key is embedded in the job acceptance commitment and attested by the device.

• Stake: Operators stake s MORPH to unlock higher tiers and increase anti-Sybil cost.

Job/Escrow Layer

A job is an on-chain record:

• Price P in MORPH, protocol fee rate f (basis points)

• Acceptance criteria hash Hcrit referencing a public JSON schema and code version

• Deadlines (taccept, tsubmit) and challenge window Tc

• Route/area commitment Cgeo (e.g., Merkle root of geohash tiles)

• Optional KYC and geofence tags

• Max concurrent accepts k

Commit-reveal:
Acceptance uses a commit-then-reveal to prevent front-running:

Cacc = H(jobId ∥ robotDID ∥ sessionPK ∥ nonce)

Proof/Oracle Layer

Robots generate an evidence Merkle tree T over signed packets; RT is the root. Artifacts (GPS trails, image hashes, IMU series) are stored off-chain and indexed by CIDs. Oracles download artifacts, validate signatures and consistency, compute quality score q ∈ [0,1], and post an attestation:

Ai = (jobId, robot, vi, qi, hi, wi)

Where:

• vi ∈ {0,1} → pass/fail

• hi → verifier code hash

• wi → oracle stake weight

Oracle selection:
Oracles are sampled per job via a verifiable random function (VRF) [3, 9] from a registry of eligible, staked oracles. The committee size m and quorum q* are parameters. Selection is unpredictable until job acceptance to reduce collusion.

Aggregation:
The settlement contract aggregates oracle votes with a stake-capped median-of-means:

Verdict = I(Σ wi vi ≥ τ)
q̂ = Median(Mean of capped buckets(qi))

With per-oracle cap wi ≤ w̄ to limit concentration.

Settlement Layer

Resolution rules:

• If no quorum → refund to poster less small fee; return stake.

• If quorum pass and no successful challenge → pay R to robot, take fee ϕ, update reputation r.

• If challenge succeeds → slash robot stake σrs and oracle stake σos, pay poster or challenger per policy, update reputations.

Safety and Liveness

Assumption 1 (Cryptography):

• Hashes are collision-resistant

• Signatures (robot, session, oracle) are unforgeable

• VRF outputs are unpredictable and unbiased to non-selected parties

Lemma 1 (Conservation of funds):
Under Assumption 1 and correct contract logic enforcing states and timeouts, total escrow for a job satisfies I6:

Escrow = payout + poster refund + protocol fees (burn + treasury) + slashes

Funds move only via deposit, fee transfer, payout, refunds, or slashing. No other method is callable in Resolved.

Lemma 2 (Quorum-safety):
If fewer than τ stake fraction of oracles are Byzantine, two conflicting verdicts cannot both finalize. With τ = 2/3, adversarial fraction ≥ 1/3 is required, similar to BFT quorum safety.

Liveness:
If at least mq of m selected oracles are online and the robot submits before tsubmit, the job resolves within Tc plus bounded delays. Governance parameters enforce max wait times:

Tmax = tsubmit − taccept + Tc + ∆chain

Censorship-resistance:
Because submission and challenges are permissionless and can be relayed via multiple RPCs or L2 inboxes, no single oracle or relayer can block progress. Any party may call resolve() after deadlines.

Protocol Parameters and Defaults

Sensitivity Analysis

• Challenge window (Tc): Larger Tc reduces false negatives but increases capital lock. Miss probability = e^(−λwTc) with watcher arrival rate λw.

• Committee size (m) and quorum (τ): Adversary with stake fraction ρ controls quorum with probability Pr[Bin(m,ρ) ≥ τm]. Example: m=7, τ=2/3, ρ=0.25 → < 1.5×10⁻². Increasing to m=9 → < 4×10⁻³.

• Stake cap (w̄): Limits influence. Setting w̄ ≤ 0.05 forces at least 20 bribed oracles for majority.

• Fee (f) and Burn (b): Treasury income = f(1−b)R. Burn = b f R counteracts incentive emissions.

4.9 Reputation/Governance Layer

• Reputation: Score r ∈ [0,1] per robot and operator. Jobs require (rmin, smin) tiers.

• Governance: MORPH-staked voting with timelocks. Parameters upgradable: (Tc, f, w̄, m, τ, α, β) and emission schedule. Must respect freeze periods and quorum thresholds.

Sequence (message fields):

1. postJob{P, Hcrit, Cgeo, Tc, f} ⇒ JobPosted(jobId)

2. accept{Cacc, s} ⇒ JobAccepted(jobId, robot?) → then reveal{robot, sessionPK, nonce}

3. submit{RT, CIDs} ⇒ ProofSubmitted

4. attest{vi, qi, hi} ⇒ Attested(quorum, qhat, verdict)

5. challenge{Bch, CIDs’, RT’} ⇒ Challenged

6. resolve() ⇒ pay/refund/slash; update reputation; Payment/Refund