Federation proposal: 1:1 RTC ↔ MRWK bridge

[Scottcjn]

@ramimbo (and @sirakinb who's been a force on the Rustchain side too) — Scott from Elyan Labs / RustChain.

Mergework's a sharp piece of work. Clean primitives, sensible tiers, and the github:<login> lazy-pay placeholder is good enough that I'm mid-fork of it for a RustChain claim portal right now (proper MIT attribution, NOTICE, repo: Scottcjn/rustchain-claim-portal).

Want to float a federated 1:1 RTC ↔ MRWK bridge.

Trust shape. Our two ledgers solve overlapping problems with different trust models: RTC is mined on real hardware (Proof of Antiquity, 8.192M cap, no mint authority), MRWK is maintainer-issued on a centralized ledger. That asymmetry means a relayer bridge — not trust-minimized — but the UX win for contributors active in both is real.

Sketch:

• RTC → MRWK. User sends N RTC to a designated bridge wallet on Node 1 (RTCbridge…). Relayer observes, waits out our 24h void window, then issues N MRWK to the user's mrwk1 address on your ledger.
• MRWK → RTC. User burns/locks N MRWK on mergework. Relayer observes, transfers N RTC from a custody wallet on our side to the user's RTC… address.

The RTC side is a lock-and-mirror — we can't mint, the cap is enforced by consensus. The MRWK side handles its own issuance via your existing maintainer-label path or a dedicated bridge role, your call.

Open questions:

1. Rate. RTC has a $0.10 internal ref scaling with holder count (published tier table). What's MRWK's ref? 1:1 to start is simplest; reassess if either gets real price discovery.
2. Relayer set. Single trusted, 2-of-2 (you + me), or 2-of-3 with a community node? I lean 2-of-2 for v1.
3. Supply accounting. Both sides need a bridged-supply counter and a way to reconcile (any cross-chain audit).
4. MRWK cap. Yours has one? Or open-ended issuance?
5. MCP. Your mcp.mrwk.ltclab.site is live; ours is queued. Worth exposing bridge ops there so AI agents can swap their own balances without a human in the loop.
6. Audit anchor. We already anchor RustChain commitments to Ergo. Could mirror bridge events there for a mutually-verifiable third leg.

Not urgent. Happy to take it slow, ship a one-way POC first, then bidirectional. Also genuinely fine with "federation isn't the right move right now" if that's where you land — mergework's a good thing regardless. Either way, sirakinb's been net-positive on our security surface (paid 638 RTC across 25 merged PRs / 13 bug reports, last week alone).

— Scott
github.com/Scottcjn/Rustchain

[ramimbo]

Scott, thanks for writing this up. I appreciate the careful framing, especially the trust-model distinction between RTC and MRWK.

MergeWork was partly inspired by RustChain while I was working around it, so this is genuinely interesting to me. The fact that the github:<login> lazy-pay pattern is useful on the RustChain side is also good validation for the primitives here.

I do want to be deliberate about next steps. MRWK today is a native MergeWork ledger coin for accepted work inside this project. MergeWork does not currently operate a public bridge, exchange, off-ramp, or public external value path, and I do not want to imply any fixed value relationship or exchange rate between MRWK and RTC before there is enough evidence and infrastructure behind it.

One concrete answer on supply: MRWK is not open-ended. MergeWork has a 100,000,000 MRWK genesis supply, and the ledger is intended to conserve that supply. Any bridge design would need to reserve, lock, or otherwise account for existing MRWK. It should not create new MRWK outside the ledger rules.

The governance work in PR #458 feels relevant here. Before any operational federation path would make sense, MergeWork needs stronger public controls around treasury actions: proposal visibility, delay, challengeability, caps, reconciliation, and clear limits on what the system can and cannot guarantee. That direction lines up with what any future integration would need.

So I’m interested, but I’d like to investigate this carefully before making an implementation commitment.

My instinct is to start with a public federation design note rather than code. That could cover the trust model, relayer/custody assumptions, MRWK supply accounting, RTC finality or void-window handling, pause/refund paths, reconciliation, failure modes, public wording, and what a safe staged rollout would look like.

On the specific open questions: 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.

A staged path might look like:

1. Settle the MergeWork governance direction.
2. Write and review a federation spec.
3. Start with read-only proof/reconciliation surfaces.
4. Only then consider a very small manually reviewed pilot if the design holds up.

I’m open to exploring this. I just want the process to be evidence-backed and auditable before it becomes operational.

[Scottcjn]

@ramimbo — fully agreed on the staged path. Design before code is the same principle we apply on Critical/High security PRs (authoritative review before merge); applying it to the federation itself is the right move.

Updates from our side based on your reply:

1. Supply parity is cleaner than I expected. RTC's 8.192M cap and MRWK's 100M conservation are both finite-and-conserved — the two systems share the same hard constraint, just at different absolute scales. That makes lock-and-mirror math unambiguous on both sides.

2. I'll write the federation design note. Public draft, posted as an RFC issue on the Rustchain side and cross-linked here. Scope per your guidance:

• Trust model + relayer assumptions (custody, multisig threshold, kill-switch)
• MRWK supply accounting (where mirrored MRWK lives during a lock — bridge custody account or escrow contract on your side; you decide)
• RTC void-window handling (24h window must elapse before MRWK is credited, otherwise voided RTC + already-credited MRWK = free MRWK)
• Pause / refund / reconciliation paths
• Public wording for users + agents
• Read-only-MCP-first design — no execution tools in v1
• Failure modes (relayer down, one side reorgs, mismatched supply counter)
• Staged rollout gates

Target: first draft within ~2 weeks, iterate publicly. No code until the design holds up under your review.

3. Will hold on MergeWork governance PR #458. Federation is downstream of that landing. Watching from a distance, not commenting unless you ask.

4. No conversion rate, no relayer set in the design note. Those are decisions for after the design holds up.

5. Ergo anchoring deferred to a later spec. Agreed it's premature.

Will ping here when the design note is ready for review. Thanks for the measured response — this is the right way to do this.