RFC: Federation bridge to mergework (RTC ↔ MRWK)

[Scottcjn]

RFC: Federation bridge to mergework (RTC ↔ MRWK)

Tracking issue for the bridge-federation proposal filed upstream at ramimbo/mergework#571.

Summary

Build a federated 1:1 relayer bridge between RTC (RustChain, real consensus, 8.192M cap) and MRWK (mergework, centralized ledger, maintainer-issued). Trust models are asymmetric — bridge is custody-and-issue on the RTC side (we can't mint), and issuance-side on the MRWK side.

Why mergework

• Closest sibling system to our bounty program. Live at https://mrwk.ltclab.site, MCP host at https://mcp.mrwk.ltclab.site.
• Two of their core contributors (ramimbo, sirakinb) are also active RustChain contributors. sirakinb alone has shipped 25 merged security PRs in the past week.
• Independent codebase (FastAPI + SQLAlchemy vs our Flask + stdlib sqlite3), no code overlap — verified by grep across 21k LOC.
• Their github:<login> lazy-pay UX is being adopted in Scottcjn/rustchain-claim-portal (MIT, with attribution to ramimbo).

Bridge sketch

RTC → MRWK: User sends N RTC to bridge wallet on Node 1. Relayer observes, waits out 24h void window, then credits N MRWK to user's mrwk1 address.

MRWK → RTC: User burns/locks N MRWK. Relayer observes, transfers N RTC from custody wallet to user's RTC… address.

Critically: RustChain side never mints. The 8.192M cap is consensus-enforced. Bridge inflows lock against a custody wallet; outflows release from it. No new RTC created.

Trust model

Relayer set: leaning 2-of-2 (Scott + ramimbo) for v1, with a path to 2-of-3 once the bridge has a few weeks of clean operation.

Open questions (mirrored from upstream)

1. Exchange rate — 1:1 to start, or USD-anchored from day one?
2. MRWK cap (if any)?
3. Expose bridge ops via MCP from the outset?
4. Anchor bridge events to Ergo for a mutually-verifiable third leg?

Status

• Proposal filed at mergework#571
• ramimbo / sirakinb response
• Design doc once trust model is settled
• Phase 0: bridge custody wallet provisioned on both sides
• Phase 1: one-way POC (RTC → MRWK, lock-and-mirror)
• Phase 2: reverse direction
• Phase 3: MCP exposure + Ergo anchoring

Not in scope

• Cross-chain consensus changes. RustChain consensus does not change.
• Off-ramps to DEX/CEX.
• Bridging to anything other than mergework in this RFC.

[ramimbo]

Thanks for tracking this here too. I replied on the MergeWork-side proposal: ramimbo/mergework#571

Short version: I’m open to exploring the idea, but I do not want to treat this as an implementation commitment yet. MRWK today is a native MergeWork ledger coin for accepted work, with a 100,000,000 MRWK genesis supply and supply-conservation expectations. MergeWork does not currently operate a public bridge, exchange, off-ramp, or public external value path.

From my side, the right next step would be a public federation design note first: trust model, custody/relayer assumptions, MRWK supply accounting, RTC void-window handling, pause/refund paths, reconciliation, failure modes, and public wording.

I would not choose a conversion rate or relayer set yet. I would also avoid bridge-specific MCP execution tools at the start; read-only MCP/status/reconciliation surfaces are a safer first step. External anchoring, including Ergo, is interesting, but I would treat it as a later spec topic after the internal event format and reconciliation model are clear.

Code should come only after the design holds up under review.

[Scottcjn]

Update: Phase 0 is partially done already.

node/bridge_api.py + tests/test_bridge_lock_ledger.py already exist in Rustchain main (see #6524 — sirakinb just hardened the confirmation-threshold path today). This means:

• The lock-ledger primitive is in place
• External-confirmation callbacks have a configurable threshold ceiling
• Test coverage exists for full deposit flow + threshold-lowering rejection

Still missing for the mergework bridge:

• Designated bridge custody wallet provisioned (RTCbridge… address with 0 starting balance)
• Relayer service (the 2-of-2 ramimbo/Scott actor — could be Sophia LLM-gated)
• MRWK-side mirror endpoint on mergework (their call; we can't build it for them)
• Bridged-supply counter on both sides (visible audit row, anchored to Ergo)
• MCP tool surface for agent-initiated swaps

@sirakinb if the upstream proposal lands, your bridge-api work directly accelerates this. Cross-reference mergework#571.

[Scottcjn]

ramimbo replied (upstream comment) and proposes a staged path:

1. Settle MergeWork governance PR FxMax-Lab I haven't received my payment #458 first
2. Public federation design note (no code yet)
3. Read-only MCP/reconciliation surfaces
4. Small manually-reviewed pilot

Agreed on our side. Next step: I'll write the design note as a follow-up RFC, post here + cross-link upstream, no code until it holds up under joint review.

Supply parity update: MRWK has a 100M genesis with conservation expectations (so it IS capped — 12.2× our 8.192M, but same shape). Lock-and-mirror math is clean on both sides.

Hold: no bridge custody wallet, no relayer commitments, no rate fix — all of those are downstream of the design note. The existing node/bridge_api.py work (sirakinb's #6524 hardening) is still useful infrastructure but does not constitute a commitment to deploy a public bridge yet.