Baseは2026年9月30日、メインネットでネットワークアップグレード「Cobalt」を有効化した。中心機能は、オンチェーン条件を満たした時だけ取引を実行候補にするValidity Transactionsと、ネイティブ資産規格B20の拡張である。
今回の変更は、DEX注文の条件設定を細かくし、トークン化資産の発行・移転管理を柔軟にする。一方、条件一致は約定保証ではなく、B20の管理機能にも発行体権限という固有のリスクが残る。
BaseのCobaltアップグレードとは
The Blockは、BaseがCobaltを稼働させ、Validity TransactionsとB20資産向けの新機能を導入したと報じた。Base公式資料によると、Base Sepoliaでは2026年9月23日、Baseメインネットでは同月30日に有効化されている。Cobaltにはこのほか、ノードがアップグレード時刻を参照するDynamic Upgradesと、TEE署名者登録のオンチェーン検証への移行も含まれる。
DEX・DeFi利用者に直接関係するのは、取引条件をシーケンサーへ伝えるValidity Transactionsだ。資産発行者やRWA事業者にとっては、B20 AssetおよびB20 Stablecoinのポリシー、差し押さえ、表示倍率の運用改善が重要になる。つまりCobaltは、Baseを単なる低コスト実行環境としてではなく、取引執行と規制対応型資産発行の双方を扱う基盤へ広げる更新と位置付けられる。
Validity Transactionsで何が変わるのか
Validity Transactionsは、署名済み取引にBaseの状態を参照する条件を添えて送信する仕組みだ。公式仕様では、残高、ストレージ、ブロック番号、Flashblockインデックスを条件として指定でき、すべての条件が一致した時にだけ取引がブロック収録の候補になる。通常のLegacy、EIP-2930、EIP-1559形式に対応し、BaseはEIP-1559を推奨している。
実用例は条件付きスワップや出金である。たとえば、UniswapやAerodromeのルーターを呼ぶ取引について、特定コントラクトの状態や残高条件が成立した場合のみ候補化する設計が考えられる。ただし、Validity Transactions自体が価格指値注文やMEV保護を自動提供するわけではない。実際のスワップ条件、最低受取額、期限などは、利用するDEXのコントラクト側でも適切に設定する必要がある。
重要なのは「条件一致」と「約定」の違いだ。条件が一致してもブロックスペースは予約されず、収録は保証されない。手数料には通常のフィーフィールドが使われ、保留中の取引を置き換える場合は送信者のnonce管理も必要になる。
条件付き取引を使う際の実務ポイント
Base公式仕様では、条件配列は署名済み取引とは別に送信され、最終的なオンチェーン取引には表示されない。ただし、これを秘密保持機能と誤解してはいけない。calldataや条件値に秘密情報を含めないよう公式資料が明記している。UniswapやAerodromeを利用するアプリでも、RPC事業者、シーケンサー、フロントエンドのログ設計まで含めて情報露出を点検すべきだ。
有効期間は、block_numberやflashblock_indexの条件で狭められる。状態変化を待つ注文を長時間放置すると、前提価格、許容スリッページ、ガス条件が古くなる可能性があるため、ウォレットやアグリゲーターは失効条件とキャンセル・置換導線を用意したい。
また、Validity TransactionsはBase固有RPCで送る機能であり、Ethereumメインネットや他のL2へ同じ挙動をそのまま移植できるとは限らない。マルチチェーン対応のDEXフロントエンドは、通常送信とのフォールバック、未収録状態の表示、nonce競合時の復旧をチェーン別に実装する必要がある。
B20はRWAとステーブルコイン向けの資産規格
B20はBaseのネイティブトークン規格で、ERC-20互換の基本操作に、ロール管理、移転ポリシー、供給上限、メモ、機能別一時停止などを追加する。EVMコントラクトとして各発行体が実装するのではなく、Base上のプリコンパイルとして提供される点が特徴だ。B20 Assetは一般資産やトークン化株式などを想定し、B20 Stablecoinは法定通貨連動型資産向けの仕様を持つ。
Cobaltでは、B20 Assetの表示倍率更新がERC-8056準拠のインターフェースへ拡張された。発行体は将来時刻を指定してUI倍率を予約できる。株式分割のような事象で、ウォレットに見せる数量を変更しながら、ERC-20の生残高、transfer量、totalSupply、allowanceを変更しない設計である。インデクサーやウォレットはbalanceOfだけでなく、balanceOfUIやuiMultiplierを参照しなければ表示上の分割を反映できない。
これはCurveやAaveのような既存DeFiとの接続を検討する際にも重要だ。プロトコルがERC-20の生残高を基準に会計する一方、ユーザー画面だけがUI残高を示す場合、表示と担保・プール会計の意味が異なり得る。統合事業者は「どの残高を経済的な基準にするか」を明示し、倍率変更イベントだけでなく有効時刻後の読み取り変化も追跡する必要がある。
複合ポリシーでKYCや制裁確認を組み合わせる
CobaltのB20改善では、Policy RegistryのUNIONとINTERSECTを使い、複数の単純ポリシーを組み合わせられる。INTERSECTはすべての子ポリシーが許可した場合に通し、UNIONはいずれかが許可すれば通す。公式例では、KYC済みアドレスのALLOWLISTと、制裁対象を拒否するBLOCKLISTをINTERSECTで結合し、送信者・受信者・mint先などのスコープへ設定できる。
この仕組みは、B20 AssetのRWAやB20 Stablecoinの発行者が、本人確認と地域・制裁ルールを別々のリストで管理する場面に向く。複合ポリシーは子リストをコピーせず参照するため、子ポリシーの更新が、それを参照する複数トークンへ反映される。
一方で、これは分散性を自動的に高める機能ではない。ポリシー管理者はアドレスの許可状態を更新でき、B20にはロール管理やseizeWithMemoなど発行体運用を支える機能もある。UniswapやAerodromeのプールへB20資産を上場する場合、受信者・送信者ポリシーがプール、ルーター、LPポジション管理と両立するかを事前検証しなければ、移転失敗や流動性の分断が起こり得る。
DEX・DeFi利用者と開発者への影響
利用者にとっての利点は、Base上で状態依存の取引をより直接的に表現できることだ。価格や残高の変化を監視する外部ボットだけに依存せず、Baseが条件を確認して収録候補を判断する。ただし、DEXのスリッページ保護、期限、ルート選択、スマートコントラクト監査は引き続き別問題である。
開発者は、まず通常取引とValidity Transactionsのライフサイクルを分離して表示したい。「送信済み」「条件待ち」「条件一致」「収録済み」「失効・置換済み」を同じ成功状態として扱うと、ユーザーが未約定を約定済みと誤認する。AerodromeやUniswap向けの条件付きスワップ画面では、条件が満たされても収録保証がないことを明示すべきだ。
B20統合では、ERC-20互換だから無条件に既存DeFiへ接続できると判断しないことが重要である。Aaveで担保候補を評価する場合は管理権限、移転制限、差し押さえ可能性、価格フィード、流動性を個別に精査する必要がある。Curve型プールでも、特定アドレスが後から拒否された場合の退出経路や緊急時対応を設計しなければならない。
まとめ
BaseのCobaltは、Validity Transactionsによって条件付き取引を導入し、B20では表示倍率の予約更新、差し押さえ機能の整理、UNION・INTERSECT複合ポリシーを追加した。DEXでは条件付きスワップや出金の設計余地が広がり、B20ではRWAやステーブルコインの運用要件をチェーン標準へ組み込みやすくなる。
ただし、条件一致は収録・約定の保証ではない。B20もERC-20互換性だけでなく、ポリシー、ロール、倍率、差し押さえ権限まで確認する必要がある。Uniswap、Aerodrome、Aave、Curveなどとの統合では、表示残高と会計残高の違い、移転制限、流動性、失効・置換処理をテストしたうえで採用を判断したい。
