cross chain spec - XibalbaTechSol/integrity-core GitHub Wiki
title: Cross-Chain Reputation Sync [PLANNED] created: 2026-07-09 updated: 2026-09-15 type: concept tags: [layer-2] confidence: low source_files:
- contracts/src/oracle/CCIPReputationBridge.sol
- README.md
[PLANNED] — not built, not deployed, not wired in. The root
README.md's "Decentralization path" lists cross-chain reputation
(syncing AIS across Base/Arbitrum/Ethereum) as a real future
step, not a current capability. This page replaces the old wiki's
cross-chain-spec.md, which described a "Canonical Reputation Registry" +
"Satellite Synchronizers" design assuming the pre-rewrite singleton
ReputationRegistry model — that model is gone (see
agent primitives), so the old design doesn't apply
as written.
Table of contents
Current state: an honest, documented gap
contracts/src/oracle/CCIPReputationBridge.sol exists in the codebase and its
per-agent clone resolution has been reworked: both send and receive resolve
the agent's ReputationRegistry through XibalbaAgentRegistry, and an
unregistered agent fails closed. The bridge remains explicitly unwired for
production: it is not deployed by Deploy.s.sol, and each agent must
opt-in by granting the bridge BRIDGE_ROLE on its own clone while operators
configure trusted peer bridges and a real CCIP lane. The contract and its
tests are therefore implemented but still [PLANNED] as a deployed
cross-chain capability.
What a real design would need to solve
Not built, but the shape a working version would have to address: per-agent clone resolution (above) instead of a single hub registry; a bridge-agnostic messaging layer (CCIP, the contract's namesake, or an alternative) rather than vendor lock-in; a minimum confirmation delay to mitigate bridge-reorg risk before a synced score is trusted on the destination chain. None of this has an implementation to point at.
Related: AIS, agent primitives, contracts.