FeryX Trades

分散型ネットワークがある数値について合意できない場合、何が起きるべきかをしばらく考えました。
ニュートンのゲートウェイは、ポリシーチェックのために二段階のコンセンサスを実行します。準備フェーズでは、ポリシーに外部データが必要な場合、各オペレーターがその値を独自に取得して、署名なしで提出します。
最初は、それが形式的なもののように聞こえました。
署名なしとは、まだ誰も何にもコミットしていないという意味です。
ゲートウェイはそれらの提出物をすべて受け取り、中央値を計算して、各個別の値がそれに対して許容範囲内に収まっているかを確認します。すべてのオペレーターが許容範囲内に収まれば、値が正規化され、合意が署名へと進みます。

I still think about the identity migration I ran two years ago, where a junior dev on my team assumed a UUID we generated ourselves would double as a namespace key. It took us four days to figure out why half our lookups came back empty. Nobody threw an error. The writes succeeded. The reads just returned nothing, because we'd invented a key nobody else was querying. That memory is what made me stop and actually cross-reference Newton Protocol's identity docs page by page, instead of trusting the first one I read.
Here's what I found: Newton's own documentation describes identity domain scoping two different ways, and they don't agree. The SDK and contract reference states that appIdentityDomain — the parameter passed into registerUserData, linkApp, and unlinkApp — is "the output of keccak256("kyc")," a fixed constant. The protocol overview page backs that up, showing identity_domain in policy params as that same fixed hash. But the integration guide describes something else entirely: it tells developers to set identity_domain as the keccak256 of their own domain string, giving keccak256(bytes("my.dev.domain.co")) as the worked example. One set of pages says the domain is fixed. Another says you choose it.
That isn't a cosmetic docs mismatch. It's the kind of ambiguity that survives review, reaches production, and only becomes visible when a second application tries to reuse identity data.
What I can verify with confidence, because it's consistent across every page I checked, is the linking flow, and the docs indicate it matters more than the domain question either way. A user encrypts their KYC data once and registers a reference on-chain through IdentityRegistry. The docs indicate that application access depends on a separate step from there: linkIdentityAsUser, called with the identity owner's address, the requesting policy client's address, the domain array, and a signature carrying a nonce and deadline. The user signs that. Every time. For every new policy client requesting access — and linkApp appears, based on the documented flow, to trigger this signed confirmation under the hood rather than granting access on its own.
That's the real distinction worth building an integration around, regardless of how the domain question eventually resolves. Storage answers what type of data this is. The signed link answers which specific application this person explicitly authorized to read it. A broker and a custodian sharing one user's KYC record still each need their own signed link before their policy checks can resolve the currently documented newton.identity.kyc.* built-ins successfully. Registering once doesn't grant access everywhere. Every app earns its own authorization, separately, whether the underlying domain hash is fixed or custom.
Here's where that gets expensive, and why the stakes are higher than a typical SDK footnote. NEWT's circulating supply sits around 291.7 million tokens against a fixed 1 billion cap, with a market cap near $9.9 million as of this week — a protocol still small enough that its entire institutional pitch rests on a handful of early integrations getting this exact flow right. Picture the stack Newton is actually selling to those integrators: a broker, a custodian, a compliance dashboard, all sharing one user base. If whoever's building that integration assumes registering KYC once is the whole job — a reasonable assumption if they only read the fixed-hash pages and never noticed the custom-domain guide — the second and third apps in that stack may never collect their signed link from the user. Their policy checks fail. Not because the KYC is invalid, and possibly not because of a domain mismatch either, but because nobody completed the specific authorization that app needed.
At this stage of adoption, a handful of botched integrations carries outsized weight. There's no large base of reference deployments to absorb the reputational cost of an institutional partner hitting this wall in production and quietly walking away from the pilot.
If Newton doesn't reconcile its own docs and make the signed-linking requirement unmissable, institutions won't discover this as a documentation quirk. They'll discover it as users failing checks they already passed, support tickets that don't map to any real KYC issue, and an onboarding funnel slower than the "register once" pitch implied.
The privacy model appears sound from the documented flow: a policy client that never collected a signed link cannot read someone's identity data, full stop — a stronger guarantee than most systems that gate access through configuration alone. The cryptography is not the weak point here. The weak point is developer guidance around the one authorization step that actually decides whether cross-app access works, buried under a function name that sounds like plain data registration rather than a consent gate.
I want to see whether Newton reconciles the fixed-hash and custom-string versions of identity_domain in a single updated reference, and whether their own example implementation walks through a real multi-policy-client sharing flow end to end — because right now, a developer building the broker-and-custodian version has to resolve contradictory guidance before they can even test the step that actually determines access.
@NewtonProtocol #Newt $NEWT