Workspace IndexPoCs › RWA across chains — the invariant nobody enforces

4RWA across chains — the invariant nobody enforces DONE

Reading a practitioner's multichain RWA architecture and finding the one box it leaves empty: who stops the tokens on five chains from summing past the asset behind them.

Re-analysed 2026-08-17 and closed as a reading note — the empty box now has an answer, though nothing is built. Source: a public LinkedIn post proposing an RWA platform architecture (Private Registry + VC + per-chain adapters), read on 2026-08-14.

Why

Almost every question this catalogue asks shows up in one place here. The post's thesis is that RWA's bottleneck is not minting tokens but carrying one off-chain fact to many chains, so the thing to standardise first is the fact-transport interface, not the token contract — which is the same enforce-on-chain-remember-off-chain split the CRE × Cloud card arrives at from the other direction. Its honest passage is the one worth keeping: verifiable credentials prove that a responsible institution signed something, and zero-knowledge proofs prove an input satisfies a condition, but neither proves the custodied asset exists. What makes it worth a card rather than a bookmark is where it stops. The author correctly names the hardest problem — in multichain, controlling global supply matters more than issuing — and then answers it with continuous reconciliation, which detects overissuance after the fact rather than preventing it. That gap is the same one the bridge and shared-sequencer cards keep circling, and it is the part to re-analyse.

How it works

The proposed stack, as written: a Private Operational Registry (Canton named as candidate infrastructure) holds the sensitive originals and the authoritative current state — custody balances, NAV, investor eligibility, total issuance, redemption and suspension status. Responsible institutions issue only the necessary facts as verifiable credentials rather than exposing the registry. A verification layer checks issuer, signature, schema, validity window and revocation, with selective disclosure or ZK where a balance or an identity cannot be shown. Per-chain adapters translate a verification result into that network's attestation format, which reduces EAS to one EVM execution adapter among several. A policy contract then permits or refuses mint, transfer, redeem and pause. The instruction the author actually gives is narrow and good: start the PoC on a single chain, but separate fact from execution from day one, so that adding a chain extends the execution channel instead of rebuilding the rights. Two notes for the re-read. First, the empty box: reconciliation detects, it does not prevent — true prevention needs each chain's mint to check and reserve against a global cap, which is cross-chain atomicity, and shared sequencers only guarantee atomic inclusion, not atomic execution. Second, the alternative this catalogue would reach for instead, following the same move that replaced bridges with intents: stop trying to hold an exact global invariant and make someone post collateral against it. An issuing agent buys an allocation from the off-chain ledger before minting and is slashed for minting without one — the invariant is enforced economically rather than atomically, exactly as a card network authorises against a limit it does not check in real time. That is likely more honest for RWA anyway, where NAV strikes daily and redemption settles T+1; the off-chain side was never atomic. The cost is the familiar one: collateral concentrates in whoever has the most capital, and under RWA licensing that is a custodian or a broker, so the structure returns to a small set of regulated intermediaries — with their collateral and slashing conditions published as code, which is the only difference and the one worth arguing about.

Re-analysis · 2026-08-17

The box is fillable, and cheaper than this card first assumed. The card reached for collateral and slashing because it read the problem as needing cross-chain atomicity. It does not. Atomicity is only required if each chain must check a global variable; it is not required if the global quantity is conserved instead of checked.

Give each chain a local allocation and let that allocation only ever move, and two local invariants multiply into the global one. The registry keeps sum(allocation) <= cap, which is a single-party rule and therefore trivial; each chain keeps minted <= allocation, which is a local read. Together they give sum(minted) <= cap with no cross-chain call anywhere. The registry in the post already holds total issuance as authoritative state, so the change is one of role rather than architecture — stop using it as an observer that reconciles after the fact, and use it as an allocator issuing a signed, nonce-bearing, expiring right to mint N units on chain X, which the per-chain policy contract consumes exactly once.

That also makes this card’s own collateral answer look over-engineered rather than clever. Slashing is what you invent when no party can be trusted, and RWA is a setting where a responsible institution is a regulatory requirement — so the card imported a trust-minimised mechanism into a context that already had a trust anchor. The closing paragraph noticed the outcome (the structure returns to regulated intermediaries) but blamed capital concentration; the actual cause is that the anchor was there all along.

What survives as genuinely unsolved

The reverse direction. Allocation can be increased safely, and reduced only down to unminted headroom; reducing below what a chain has already minted requires burning there first, which is impossible if that chain is halted or dead. Revocation would fix it, and revocation is inflation — whoever can cancel an allocation can re-issue it, and if the chain was merely unreachable rather than dead, the total is breached. Stranded allocation, plus the challenge window and evidence standard that would govern recovery, is the part still worth building against.

Two smaller corrections

Exact agreement was never the target, because the off-chain side was never atomic either: NAV strikes daily and redemption settles T+1. The goal is a stated bound on staleness, not the absence of it.

Open on jaylabs.xyz →


한국어

4멀티체인 RWA — 아무도 강제하지 않는 불변식 DONE

실무자의 멀티체인 RWA 아키텍처 제안을 읽고, 그 설계가 비워둔 칸 하나를 찾은 기록 — 다섯 체인의 토큰 합계가 기초자산을 넘지 않게 누가 막는가.

2026-08-17 재분석 완료 — 빈칸에 답을 적었고, 구현물은 없습니다. 출처: RWA 플랫폼 아키텍처(Private Registry + VC + 체인별 어댑터)를 제안한 공개 LinkedIn 글, 2026-08-14 읽음.

이 카탈로그가 묻는 질문이 거의 전부 한 자리에 나옵니다. 글의 논지는 RWA의 병목이 토큰 발행이 아니라 오프체인 사실을 여러 체인에 전달하는 일이고, 그래서 먼저 표준화할 것은 Token Contract가 아니라 사실 전달 인터페이스라는 것 — CRE × Cloud 카드가 반대 방향에서 도달한 "강제는 온체인, 기억은 오프체인"과 같은 분리입니다. 살릴 만한 정직한 대목: VC는 책임기관이 서명했다는 사실을, ZKP는 입력이 조건을 만족한다는 사실을 증명할 뿐 수탁자산이 실제로 존재하는지는 증명하지 못한다. 북마크가 아니라 카드가 될 값어치는 글이 멈추는 자리에 있습니다. 저자는 가장 어려운 문제를 정확히 짚고도("멀티체인에서는 발행보다 글로벌 공급량 통제가 더 중요하다") 그 답을 지속적 대사(reconciliation)로 둡니다 — 과발행을 사전에 막는 것이 아니라 사후에 발견하는 방식입니다. 그 빈칸이 브릿지·공유 시퀀서 카드가 반복해서 부딪히는 바로 그 지점이고, 다시 분석할 부분입니다.

동작 방식

글이 제안한 스택 그대로: Private Operational Registry(후보 인프라로 Canton을 명시)가 민감한 원본과 최신 기준 상태를 보관합니다 — 수탁잔고·NAV·투자자 자격·총발행량·상환과 정지 상태. 책임기관은 레지스트리를 공개하는 대신 필요한 사실만 VC로 발급합니다. 검증 계층이 발급자·서명·schema·유효기간·폐기를 확인하고, 잔고나 신원을 드러낼 수 없는 경우 선택적 공개나 ZKP를 씁니다. 체인별 어댑터가 검증 결과를 그 네트워크의 attestation 형식으로 변환하며, 이 구조에서 EAS는 여러 EVM 실행 어댑터 중 하나로 내려앉습니다. 그다음 Policy Contract가 mint·transfer·redeem·pause를 허용하거나 거절합니다. 저자가 실제로 주는 지시는 좁고 좋습니다 — PoC는 단일 체인에서 시작하되, 처음부터 사실과 실행을 분리하라. 그래야 체인을 추가할 때 현실의 권리를 다시 만들지 않고 실행 채널만 넓힙니다. 다시 읽을 때의 메모 둘. 첫째, 빈칸: 대사는 발견이지 예방이 아닙니다 — 진짜로 막으려면 각 체인의 mint가 전역 한도를 확인하고 예약해야 하는데 그것이 곧 체인 간 원자성이고, 공유 시퀀서는 원자적 포함까지만 보장합니다. 둘째, 이 카탈로그라면 택했을 대안 — 브릿지를 인텐트로 대체한 것과 같은 수를 씁니다: 정확한 전역 불변식을 붙들려 하지 말고 누군가 담보를 걸고 그것을 보증하게 하는 것. 발행 대리인이 mint 전에 오프체인 기준원장에서 배정을 사오고, 배정 없이 찍으면 슬래싱 — 불변식을 원자적으로가 아니라 경제적으로 강제합니다. 카드사가 실시간 조회 없이 한도에 대해 승인하고 나중에 정산하는 것과 정확히 같은 구조입니다. RWA에는 오히려 이쪽이 정직합니다 — NAV는 하루 한 번 산정되고 상환은 T+1인데, 오프체인이 애초에 원자적이지 않았으니까요. 대가는 익숙한 것: 담보는 자본이 큰 쪽으로 집중되고, RWA는 라이선스까지 걸려 결국 수탁사·증권사 몇 곳이 그 자리에 섭니다. 구조가 기존 금융으로 되돌아오는 셈이고 — 다른 점은 담보와 슬래싱 조건이 코드로 공개된다는 것 하나뿐인데, 그 하나가 얼마짜리인지가 다툴 만한 지점입니다.

재분석 · 2026-08-17

빈칸은 채울 수 있고, 이 카드가 처음 가정한 것보다 싸게 채워집니다. 카드가 담보와 슬래싱을 꺼낸 것은 이 문제를 체인 간 원자성이 필요한 문제로 읽었기 때문입니다. 그렇지 않습니다. 원자성은 각 체인이 전역 변수를 검사해야 할 때만 필요하고, 전역 수량을 검사하는 대신 보존하면 필요 없습니다.

각 체인에 로컬 배정(allocation)을 주고 그 배정은 오직 이동만 하게 하면, 로컬 불변식 둘이 곱해져 전역 불변식이 나옵니다. 레지스트리가 Σ allocation <= 한도를 지키고(단일 주체라 자명), 각 체인이 minted <= allocation을 지키면(로컬 읽기), 합쳐서 Σ minted <= 한도체인 간 호출 없이 성립합니다. 글의 레지스트리는 이미 총발행량을 권위 있는 상태로 쥐고 있으므로, 바뀌는 것은 아키텍처가 아니라 역할 하나입니다 — 사후에 대사하는 관찰자로 쓰지 말고, 체인 X에 N 단위를 발행할 권리를 논스·만료 포함해 서명 발급하는 배분자로 쓰고, 체인별 Policy Contract가 그것을 정확히 한 번 소비하게 하는 것.

그러면 이 카드가 내놓았던 담보 답안은 영리한 것이 아니라 과잉설계로 보입니다. 슬래싱은 믿을 주체가 하나도 없을 때 나온 발명인데, RWA는 책임기관의 존재가 규제 요건인 판이라 — 카드는 신뢰 앵커가 이미 있는 문맥에 무신뢰 도구를 수입한 셈입니다. 마지막 문단이 결과(구조가 규제 중개기관으로 되돌아온다)는 알아챘지만 원인을 자본 집중으로 돌렸는데, 실제 원인은 앵커가 처음부터 거기 있었다는 것입니다.

진짜로 안 풀린 채 남는 것

반대 방향입니다. 배정은 안전하게 늘릴 수 있고, 줄이는 것은 아직 안 찍은 여유분까지만 가능합니다. 이미 찍힌 양 아래로 내리려면 그 체인에서 먼저 소각해야 하는데, 체인이 멈췄거나 죽었으면 소각할 방법이 없습니다. 폐기 권한을 주면 풀리지만 폐기 권한 = 인플레이션 권한입니다 — 배정을 취소할 수 있는 자는 재발행할 수 있고, 그 체인이 죽은 게 아니라 잠시 닿지 않았을 뿐이라면 총량이 깨집니다. stranded allocation, 그리고 회수를 규율할 챌린지 기간과 증거 기준 — 여기가 아직 만들어 볼 값어치가 남은 부분입니다.

재독이 낳은 작은 정정 둘

완전 일치는 애초에 목표가 아니었습니다 — 오프체인도 원자적이었던 적이 없기 때문입니다. NAV는 하루 한 번 산정되고 상환은 T+1이니, 목표는 시차 0이 아니라 시차의 상한이 명시되는 것입니다.

Open on jaylabs.xyz →


원문 보관 · 2026-08-14 읽음

RWA는 토큰 발행이 아니라, 현실의 권리를 멀티체인에 연결하는 일입니다

인용 안내. 아래는 이 카드가 분석 대상으로 삼은 제3자의 공개 글 원문이다(LinkedIn, 2026-08-14 읽음). 위쪽 카드 요약의 주장과 구분하기 위해 손대지 않고 그대로 보관한다 — 나중에 다시 분석할 때 어디까지가 저자의 논지이고 어디부터가 내 해석인지 헷갈리지 않게. 저작권은 원저자에게 있으며, 개인 학습 기록 목적의 보관이다.

최근 업비트의 GIWA Dojang과 Ethereum Attestation Service(EAS)를 보면서 RWA를 실제로 구현하는 방향을 다시 생각하게 됐습니다. Dojang은 업비트가 확인한 지갑 주소, 특정 시점의 잔고, 잔고 데이터의 Merkle root 같은 오프체인 정보를 GIWA Chain에서 검증 가능한 attestation으로 발급합니다.

개인정보 원문을 체인에 올리지 않으면서도, 누가 어떤 사실을 확인했는지, 그 증명이 아직 유효한지, 온체인 애플리케이션이 확인할 수 있게 만드는 구조입니다.

단일 체인과 단일 발행자만 본다면 이 방식은 상당히 명확합니다. 신뢰할 발행자를 등록하고, 공통 schema를 정하고, EAS로 증명을 발급하고, Resolver와 Smart Contract가 증명 결과를 읽어 실행하면 됩니다.

그런데 실제 RWA도 한 체인 안에서만 운영될까요?

RWA 상품은 투자자와 유동성이 있는 곳을 따라 여러 네트워크에 발행될 가능성이 높습니다. 같은 단기채 펀드가 Ethereum, Base, 다른 EVM 네트워크, 나아가 서로 다른 기관 원장에서 유통될 수도 있습니다.

이때부터 질문이 달라집니다.

  • 각 체인이 동일한 KYC와 수탁 정보를 다시 확인해야 할까.
  • 한 체인에서 상품이 정지되면 다른 체인도 즉시 정지되는가.
  • 전체 기초자산이 100억원인데 여러 체인의 토큰 공급량 합계가 이를 넘지 않는다고 누가 보장하는가.
  • 어느 기록이 최종적인 기준인가.

최근 RWA SoK 논문은 이를 오프체인 원장의 법적 진실과 온체인 스마트컨트랙트의 계산적 진실을 계속 동기화해야 하는 dual-state system으로 설명합니다. 체인마다 별도의 schema, attester, registry를 만들면 발행 채널이 늘어날수록 같은 사실을 반복해서 등록하고 검증해야 합니다. EAS는 여러 EVM 체인에서 사용할 수 있습니다. 하지만 서로 다른 체인의 증명을 자동으로 하나의 금융상 사실로 만들어주지는 않습니다.

그래서 먼저 표준화해야 하는 것은 Token Contract가 아니라 오프체인 사실을 전달하는 공통 인터페이스라고 생각합니다.

여기에 Verifiable Credential이 적합할 수 있습니다

VC는 특정 기술 제품이 아니라, 누가 발급했는지, 무엇에 관한 주장인지, 언제부터 언제까지 유효한지, 어떤 schema를 따르는지, 정지되거나 폐기됐는지, 어떤 서명으로 검증할 수 있는지를 표현하는 체인 중립적인 credential envelope입니다.

다만 VC만 도입한다고 RWA 데이터 표준이 완성되는 것은 아닙니다. assetId, NAV, snapshotAt, custodyStatus, chainAllocation처럼 실제 금융업무에서 사용할 공통 schema는 참여기관이 별도로 합의해야 합니다. VC를 쓴다고 DID가 반드시 필요한 것도 아닙니다. 여러 기관의 검증키를 공통 방식으로 발견하고 교체해야 할 때 선택적으로 사용할 수 있습니다.

최근 xRWA 논문도 asset, identity, compliance, custody 정보를 VC로 구성하고, 한 네트워크에서 확인한 자산을 다른 네트워크가 재사용하는 구조를 제안합니다. 아직 시뮬레이션 단계지만 문제를 바라보는 방향은 흥미롭습니다.

제가 생각하는 플랫폼 구조는 다음과 같습니다

Private Operational Registry가 수탁잔고, NAV, 투자자 자격, 전체 발행량, 상환과 정지 상태 등 민감한 원본과 최신 기준 상태를 관리합니다. 여기에는 캔톤 네트워크 같은 인프라가 활용될 수 있습니다.

수탁기관, 사무관리사, 신원확인기관 등 책임기관은 필요한 사실만 VC로 발급합니다. 모든 원본 데이터를 공개할 필요는 없습니다.

검증 계층은 발급자, 서명, schema, 유효기간, 폐기 상태를 확인합니다. 개인정보나 잔고 원문을 노출하기 어려운 경우에는 선택적 공개나 ZKP를 결합해 “적격 투자자인가”, “잔고가 기준 이상인가” 같은 조건만 증명할 수 있습니다.

각 체인의 Adapter가 검증 결과를 EAS 또는 해당 네트워크의 attestation 형식으로 변환합니다. 이 구조에서 EAS는 EVM 실행 어댑터 중 하나가 됩니다.

Policy Contract가 검증 결과와 Private Registry의 기준 상태를 바탕으로 mint, transfer, redeem, pause를 허용하거나 거절합니다.

운영 계층은 모든 체인의 공급량과 오프체인 기준원장을 계속 대사합니다. 멀티체인에서는 발행보다 글로벌 공급량 통제가 더 중요합니다.

여기서 VC와 ZKP가 현실의 진실을 만들어주는 것은 아닙니다

VC는 책임기관이 그 내용에 서명했다는 사실을 증명합니다. ZKP는 주어진 입력이 조건을 만족한다는 사실을 원문 없이 증명합니다. 수탁자산이 실제로 존재하는지, NAV가 정확한지, 법적 권리가 유효한지는 여전히 수탁기관·발행자·감사인·등록기관의 책임입니다.

따라서 PoC는 단일 체인에서 시작해도 됩니다. 다만 처음부터 사실과 실행을 분리해야 합니다. 사실은 Private Registry와 VC에 두고, 정책은 교체 가능한 검증 계층에 두고, 실행은 체인별 Adapter와 Token Contract에 둡니다. 그러면 새로운 체인을 추가할 때 현실의 권리와 데이터를 다시 만드는 대신 실행 채널만 확장할 수 있습니다.

RWA의 효용도 발행한 토큰 수로 평가하면 안 됩니다

  • 중복 KYC가 얼마나 줄었는지.
  • 발행과 상환 시간이 얼마나 짧아졌는지.
  • 과발행과 자격 없는 이전을 막을 수 있는지.
  • 기관 간 대사와 감사 비용이 얼마나 줄었는지.
  • 다른 금융 애플리케이션이 그 권리를 담보나 결제에 재사용할 수 있는지.

결국 RWA 플랫폼은 한 체인 위의 토큰 발행기가 아닙니다. 현실의 권리와 상태를 Private Registry에서 관리하고, 책임기관의 증명을 공통 형식으로 전달하고, 각 네트워크의 정책과 실행으로 연결하는 멀티체인 금융 운영 시스템이어야 합니다.

← 15. Stake concentration risk79. Institutional custody study →