Sattar Chaqer

この報酬をくれたビンナンス・スクエアに、心から本当に感謝します 🤍

時間が経つにつれて、私はさまざまなキャンペーンに参加し、何時間も読んだり書いたり編集したりしてきました。ときには、その努力が報われるのか不安になることもありました。だから、GENIUS OpenLedger SIGN NIGHT や XPL のようなキャンペーンから報酬が届くのを見ると、本当に嬉しいです。

私にとってそれは、報酬そのものだけではありません。自分の仕事が見てもらえたという感覚でもあるのです。どの投稿にも時間がかかり、どのキャンペーンも私に違うことを教えてくれて、そして得られた結果は、次も続けていくための理由をもう一つ与えてくれました。

クリエイターにこうした機会を作ってくれたビンナンス・スクエアに感謝しています。あわせて、途中で私の投稿を支えてくれたすべての方にも感謝しています。読んでくれた方、コメントしてくれた方、共有してくれた方、どれであっても、私はとてもありがたく思っています。

こういう小さな瞬間が、継続することの大切さを改めて教えてくれます。

ビンナンス・スクエアにありがとう。 🙏

#BinanceSquare #creatorpad #Binance @Binance Square Official

I keep noticing that blockchains are very good at deciding whether a transaction is valid but that doesn’t automatically mean the transaction should be allowed.

Validity is mostly a technical question. Is the signature correct? Does the wallet have the funds? Will the contract call execute under the rules of the chain? If yes the blockchain can process it.

But financial systems usually need a second test.

A transaction can be perfectly valid onchain and still violate a treasury rule a vault mandate an issuer restriction or an authorization policy tied to that capital. That’s the distinction Newton is built around.

To me this is one of the clearest ways to understand the protocol.

Newton doesn’t replace blockchain settlement. It adds a layer before settlement that asks a different question not just can this transaction execute but is this transaction actually permitted under the rules attached to it?

That’s a much stronger standard than validity alone.

@NewtonProtocol $NEWT #Newt $TAC $LAB

#BinanceTurns9 Binance Turns 9 - Build By You

2.1 years on Binance, and the journey keeps getting better. Happy 9th anniversary to the platform that never stops building!

One thing that stands out to me about Newton is that it treats authorization as an actual transaction flow instead of a vague approval step somewhere before settlement. In a normal onchain process a user signs a transaction sends it to the blockchain and the network checks whether it is valid under protocol rules. If it is execution happens and settlement records the result. Most of the logic is concentrated at the execution layer. Newton inserts another layer into that lifecycle. A transaction doesn’t move directly from user intent to settlement. It first enters an authorization flow where the action is proposed evaluated against policy agreed on by the network turned into a signed result, and then checked again before execution is allowed to proceed. That sequence matters because it gives authorization an actual structure. The proposed action enters as intent. That intent goes through evaluation against the relevant rules. The network reaches consensus on the outcome. The result becomes a signed attestation. Then enforcement decides whether the transaction can execute. What I find interesting is that Newton is not just saying transactions should be checked before value moves. It is defining how that check happens and what the output of that process looks like before settlement ever begins. That makes authorization feel less like a general compliance claim and more like infrastructure with its own workflow inside the transaction lifecycle.

@NewtonProtocol $NEWT #Newt $TLM $VANRY

What is Newton adding onchain?

みなさんようこそ

みなさんようこそ

オンチェーン・ファイナンスで私が特に目にするのは、コンプライアンスが「結果」として示されるのではなく、「プロセス」として語られることがいかに多いかという点です。あるプラットフォームはウォレットをスクリーニングしたと言います。あるバル ト管理者は指示（マンダート）に従ったと言います。あるプロトコルは、アクションを進める前に関連するルールを確認したと言います。どのケースでも、ユーザーは結局、ワークフローのどこかに適切な統制が存在していたのだと信じるよう求められています。私が繰り返しそこに立ち返るのは、その部分です。コンプライアンスの約束は、チームが何が起きたと言っているのかを教えてくれます。しかし、価値を移転した実際のトランザクションにおいて、そのルールが実際に執行されたことを必ずしも証明するものではありません。ニュートンのアプローチは、その点で違って感じます。コンプライアンスをトランザクションそのものにより近づけるからです。単に「チェックは行われた」と言うのではなく、ニュートンは、実行前に、特定のトランザクション意図に紐づいた署名された認可結果を生成するよう設計されています。言い換えれば、このシステムはトランザクションの周辺にある統制を説明するだけではありません。価値が移る前にポリシーが評価されたことを、検証可能な記録として作り出します。その違いは、聞こえよりもずっと重要です。約束はたいてい、社内のワークフローやダッシュボードのようなプロセス文書の中に存在します。一方で、レシート（受領証）は実際のトランザクションの経路にずっと近い場所に存在します。これは、定義されたポリシーのもと、定義された時点でそのトランザクションが確認されたという証拠になります。私にとって、これこそがニュートンが起こしている本当の変化です。コンプライアンスを「プラットフォームが実施した」と主張するものから、「インフラが実際に示せる」ものへと変えるのです。そして、信頼を求めずに価値を動かすことを前提としたシステムにおいて、それは「チェックを実行した」と言うだけよりも、はるかに強い基準に感じられます。

@NewtonProtocol $NEWT #Newt $LAB $VANRY

コンプライアンスでより重要なのは何ですか？

私は、暗号資産のアプリがユーザーのチェックを「取引の前に起きるもの」として扱い、取引そのものを形づくる要素として扱っていないことに、ますます気づきます。

プラットフォームは、ウォレットが特定の機能にアクセスできるか、市場に参入できるか、あるいは特定のプロダクトフローを利用できるかを判断します。そのアクセス判断が下された後、実際のオンチェーン操作は、通常は別のステップとして扱われます。ユーザーは入口は通れるのですが、取引のルート自体は、そうした条件がもはや関係ないかのように振る舞い続けます。

ニュートンのアーキテクチャを見るほど、その分離は構造的な弱点なのではないかと思えてきます。

重要なのは、旅の途中でプラットフォームがユーザーを先にチェックしたかどうかだけではありません。重要なのは、取引がまさに実行されようとする瞬間に、その関連するユーザー条件を取引が評価できるかどうかです。これが、私がニュートンのアイデンティティ・オラクルに見ている転換です。

ユーザー情報をアクセス制御の期間中だけ「重要」として扱うのではなく、ニュートンは選択したユーザー属性を認可入力として組み込みます。地域ステータスの適格性条件やその他のユーザーに紐づくルールは、承認フローそのものの一部になりえます。するとシステムは、単に「ユーザーがプロダクトに入れたか」を問うだけではなく、「この特定の取引が、この特定のポリシーのもとで許可されるべきか」を問うことができます。

それは、オンチェーン・ファイナンスの中でこれらのチェックが担う役割を変えます。

それらは、アプリへの単なる門番（ゲート）であることをやめます。

取引の意思決定そのものの一部になります。

私にとって重要なのはここです。ニュートンは、機密性の高い個人情報を公開されたオンチェーンの取引レイヤーから切り離したまま、ユーザーに紐づくルールを「実際に価値が動く場所」により近づけようとしています。

その結果、このモデルははるかに実用的になります。

暗号資産をアイデンティティ・システムに変えるからではありません。

しかし、オンチェーンアプリがユーザー条件を、別個のオフチェーン手順として残しておき、アプリが開いた後はもう効かなくなってしまうのではなく、「プログラム可能な取引ロジック」として扱えるようになるからです。

@NewtonProtocol $NEWT #Newt $HMSTR $LAB

では、ユーザーの適格性はオンチェーン・ファイナンスにおいて、どこで最も重要になるべきでしょうか？

さあ、クラムを取りに行こう

暗号資産のアプリが、インターフェース上の制限と実際の強制（enforcement）をまだ混同していることに、私はずっと気づいています。フロントエンドはボタンを隠したり、地域をブロックしたり、ウォレットが特定の機能を使えないように見せたりできるのです。表面的にはコンプライアンスに見えます。ユーザーにはその制限が見えるし、アプリは目に見える操作レイヤーを指し示して「チェックは整っています」と主張できます。ですが、それらは取引そのものが実際に統制されていることを意味しません。

スマートコントラクトが直接呼び出せるのであれば、そのルールは「価値が移動する場所」には存在していないのです。それは契約の上に載るアプリ層にとどまっています。これにより“うっかりした誤用”は減るかもしれませんが、取引レベルでの実効的な強制にはなりません。これこそが、Newtonが解決しようとしている弱点です。

Newtonの枠組みでは、コンプライアンスは「ユーザーが承認済みのインターフェース内に留まるかどうか」に依存すべきではありません。承認（authorization）の時点、つまり取引が認可される地点で、決済の前に強制されるべきです。そのためPersonaの統合が私にとって重要なのです。単に身元や居住地を証明するだけではありません。これらの属性を認可パスの中で活用し、実行の前に取引を評価できるようにすることで、フロントエンドで単にフィルタするだけ、という状態から脱するのです。

そしてそれは、基準をまったく変えてしまいます。

フロントエンドの制御だけだと「アプリの中でこの操作を止めようとしました」と言うことになります。取引レイヤー側の制御なら「この操作は、ポリシーを満たさない限り実行できません」と言えます。これはずっと強い主張です。

オンチェーンの金融では、本当の問いは「インターフェースがクリックをブロックしたかどうか」ではありません。本当に問うべきは「コントラクトへの経路がまだ開いていたか」です。開いていたなら、コンプライアンス規則は常に迂回可能だったということになります。

だからこそ、私はNewtonのアーキテクチャが重要だと思っています。コンプライアンスをUIレベルの制限から切り離し、取引が実際に“本物”になる場所へ近づけるからです。暗号資産の世界では、スマートコントラクトが最終的なゲートです。コンプライアンスがその層まで届かなければ、それはまだ「制御すべき対象」から一段ズレた場所で働いていることになります。

@NewtonProtocol $NEWT #Newt $TLM $ARPA
暗号資産のコンプライアンスは、どこで実際に強制されるべきでしょうか？

暗号資産のコンプライアンスが、取引そのものの中に内在するロジックではなく、取引の周りにくっついた書類の手続きのように扱われ続けていることに、私はずっと気づかされます。

そのモデルは、承認の制限や審査が別々の業務レイヤーとして存在し得る、古い金融システムでは理にかなっていました。ですがオンチェーン・ファイナンスはそうではありません。スマートコントラクトは自動的に実行されて価値の決済は素早く行われ、取引が止まってコンプライアンスチームが事後に手作業でポリシーを解釈できるようにはなっていません。

決済がすでにプログラマブルであるなら、コンプライアンスもおそらくプログラマブルになる必要があります。

その点が、ニュートン・プロトコルの中でも特に興味深いところです。

ニュートンは、コンプライアンスを取引に付随する外部のチェックリストとして扱いません。ポリシーを、実行の前にシステムが評価できるものへと変換します。RegoやOpen Policy Agentのようなツールを使って、トランザクションのルールを、PDFの社内手順やハードコードされたプロダクトロジックの奥に埋もれたものではなく、機械が読める論理として記述できるようになるのです。

それはコンプライアンスの役割をまったく変えます。

取引上限はプログラマブルなロジックになります。

管轄（ジャーリスディクション）の制限もプログラマブルなロジックになります。

投資家の適格性要件もプログラマブルなロジックになります。

制裁（サンクション）の確認もプログラマブルなロジックになります。

これらのルールがコードとして表現されると、コンプライアンスはゆるい運用プロセスではなくなり、インフラのように振る舞い始めます。価値が動く前に、ソフトウェアが一貫して評価できるものになるのです。

私にとって、それがニュートンが押し進めている本当の転換です。

スマートコントラクトが決済をプログラマブルにした。

ニュートンは同じことをポリシーに対してしようとしています。

そして、オンチェーン・ファイナンスがより本格的な金融活動を支えるのであれば、コンプライアンスがずっとシステムの外側に置かれた書類として留まるわけにはいかないでしょう。

@NewtonProtocol $NEWT #Newt $M $US

コンプライアントなオンチェーン・ファイナンスにとって最大のボトルネックは何ですか？

ライブに参加 @RaDhika_08

以前は、認可と決済は同じ取引プロセスの別名にすぎないと思っていました。金融インフラをより深く調べるほど、それらはまったく異なる課題を解いているのだと気づきました。

決済とは、価値の最終的な移動です。残高記録を更新し、所有権の変更を反映し、ブロックチェーン上で取引の最終状態を確定させます。こここそがパブリック・ブロックチェーンが長年その強みを証明してきた領域です。

一方、認可は別の目的を果たします。

認可は実行の前に行われ、「この取引は前に進めるべきか？」という1つの問いに焦点を当てます。結果を記録するのではなく、決済が始まる前に認可が取引を評価します。

従来の決済ネットワークは、この責務を常に分けてきました。支払い要求はまず認可され、その後に決済されます。各段階は異なる役割を担い、価値が移転される前に金融システムが判断できるようにします。

私の関心を引いたのは、Newton Protocolがオンチェーン・ファイナンスにもこの同じアーキテクチャ上の原則を適用していることです。

ブロックチェーンの決済を変えるのではなく、Newtonは実行の前に取引の意図を評価する専用の認可レイヤーを導入します。決済はそのまま得意なことを続け、認可が取引ライフサイクル内で別の責任として担うようになります。

考えれば考えるほど、この分離は理にかなっていると感じます。

決済は「何が起きたか」に答えます。

認可は「それが起きるべきか」に答えます。

それらは別の問いであり、別のインフラが必要です。

この違いを理解したことで、私のブロックチェーン・アーキテクチャの見方が変わりました。オンチェーン・ファイナンスの未来は、決済の改善だけに依存しないかもしれません。認可と決済が同じ仕事をしようとするのではなく、互いを補完し合うときに最も効果を発揮するのだと認識することが、同様に重要になる可能性があります。

@NewtonProtocol $NEWT #Newt

オンチェーン・ファイナンスの未来にとって、どのレイヤーの方がより重要でしょうか？