マルチシグ・ガバナンスを備えた、更新版の QBridge1) スマートコントラクト をQubic上にデプロイ（展開）することを許可します。
QBridgeは、QubicブロックチェーンとEthereum（イーサリアム）を接続する、ノンカストディアル（非中央集権型）のクロスチェーン・ブリッジです。
誰もが数秒でQubicとETHの間でQUBICトークンを転送できるようにするもので、2-of-3（3名中2名）のマルチシグ・ガバナンス・モデルを活用し、単一の当事者が管理者操作、手数料の引き出し、またはマネージャーの変更を一方的に制御できないように保証します。
目標: 摩擦のない相互運用性（インターオペラビリティ）を解放し、ビルダーやユーザーが単一のエントリーポイントから両チェーンの流動性、dAppエコシステム、開発者ツールにアクセスできるようにすることです。
—
| 機能 | 説明 |
|---|---|
| 2-of-3 マルチシグ・ガバナンス | すべての重要な管理者操作（管理者の変更、マネージャーの追加/削除、手数料の引き出し、しきい値の変更）には、提案システムを通じて少なくとも3名中2名のマルチシグ管理者の承認が必要です。単一障害点や信頼の集中が存在しません。 |
| 提案ベースの管理者アクション | 管理者の変更は、createProposal / approveProposal のフローを通じて行われます。提案は作成者によってキャンセル可能です。しきい値に達すると、アクションはアトミック（不可分）に実行されます。 |
| ラップされた資産の発行/焼却 | QUBICトークンをEthereumに移動すると、元のトークンはロックされ、ERC-20の wQUBIC が1対1でミントされます。逆の経路ではラッパートークンがバーンされ、ネイティブのQUBIC資産のロックが解除されるため、常に供給量のパリティ（等価性）が保証されます。 |
| 手数料予約システム | 保留中の注文からの手数料は予約され、注文が完了するか返金されるまで分配されません。これにより、返金される可能性のある注文に対する早期の手数料分配を防ぎます。 |
| ガス最適化バッチリレー | Qubic側の手数料はごくわずかです。Ethereum側では、ブリッジが複数の証明を単一のトランザクションにバッチ化（束ねる）することで、ガス代を償却し、ユーザーコストを削減します。 |
| クロスチェーン・メッセージバス | トークンだけでなく、QBridgeはQubicのコンピュートレイヤーとEthereumのDeFiスタックにまたがるマルチチェーンdAppのために、任意のペイロード（ガバナンス投票、オラクルデータ、コントラクト呼び出し）を転送します。 |
| 即時流動性プール | ファイナリティ（確定）を待てないユーザーのために、LP（流動性提供者）が裏付けとなるプールが「流動性バウチャー」を提供し、資産が即座に到着するようにします。その際、LPは少額の手数料を獲得します。 |
| 統合されたウォレットUX | Qubicウォレットや人気のあるETHウォレット内でワンクリックのブリッジが可能です。プログレスバーにより両チェーンでの確認状況が表示されます。 |
| 監査済み・オープンソース | すべてのコントラクトとバリデーターのコードはオープンソースです。コントラクトは監査されており、すべての指摘事項に対処済みです（下記の「組み込まれた監査修正」セクションを参照）。 |
| 低手数料モデル | ブリッジは合計1%の手数料（オペレーター0.5% + ネットワーク0.5%）を徴収し、スパムを防ぐために最小注文額を200 QUに設定しています。 |
| 返金保護 | すべてのエラー経路で、トークンと手数料がユーザーに返金されます。2フェーズコミット・パターンにより、トークンが失われないことを保証します。 |
—
ブリッジは各注文に対して合計1%の手数料を徴収し、以下のように2つに分割されます：
| 手数料 | 割合 | 送信先 |
|---|---|---|
| オペレーター手数料 | 0.5% | feeRecipient ウォレットを通じてVottunに分配 |
| ネットワーク手数料 | 0.5% | distributeDividends を通じてコンピュター（株主）に分配 |
—
コントラクトは、すべての管理操作に対して2-of-3（3名中2名）のマルチシグモデルを使用します：
| 種類 | アクション |
|---|---|
SET_ADMIN | 既存のマルチシグ管理者を新しいアドレスに置き換える |
ADD_MANAGER | 新しい運用マネージャーを追加する（最大3名） |
REMOVE_MANAGER | 運用マネージャーを削除する |
WITHDRAW_FEES | 蓄積されたオペレーター手数料を引き出す |
CHANGE_THRESHOLD | 必要な承認のしきい値を変更する（最小2） |
createProposal を通じて提案を作成する（自動的に1つ目の承認としてカウントされる）approveProposal を通じて承認するcancelProposal を通じて保留中の提案をキャンセルできるcompleteOrder、refundOrder、addLiquidity を実行できる運用上の役割—
コントラクトは、セキュリティ監査で指摘されたすべての問題に対処しています：
| ID | 修正内容 |
|---|---|
| QVB-02 | 注文用のシングルパス・スロット割り当て（1回のループで空きを見つける、またはリサイクルする） |
| QVB-03 | リサイクルを伴うシングルパスの提案スロット検索 |
| QVB-04 | 冗長な netAmount 変数の削除 |
| QVB-09 | 最小注文額の導入、createOrder 時の流動性予約、ゼロ手数料スパムの防止 |
| QVB-10 | すべてのエラー経路でのトークン返金（transferToContract、addLiquidity） |
| QVB-11 | invocationReward() を即座にキャプチャし、超過支払いを返金 |
| QVB-12 | 転送優先パターン：転送が成功した後にのみ状態を更新 |
| QVB-13 | transfer() の戻り値を >= 0 でチェック（truthy判定ではなく） |
| QVB-17 | 注文の作成に成功した場合にのみ nextOrderId をインクリメント |
| QVB-18 | ETHアドレスがすべてゼロでないことを検証、提案アドレスが NULL_ID でないことを検証 |
| QVB-20 | 基礎となるアクションが成功した場合にのみ、提案を実行済みとしてマーク |
| QVB-21 | 2フェーズコミット：transferToContract で tokensReceived を設定し、completeOrder で tokensLocked を設定 |
| QVB-22 | transferToContract でのEVMからQubicへの注文を拒否（その方向には適用されないため） |
—
関数（読み取り専用）:
| ID | 関数 | 説明 |
|---|---|---|
| 1 | getOrder | IDによる注文の詳細の取得 |
| 2 | isManager | アドレスがマネージャーかどうかを確認 |
| 3 | getTotalReceivedTokens | これまでに受信した総トークン数 |
| 4 | getTotalLockedTokens | 現在ロックされているトークンの残高 |
| 5 | getOrderByDetails | ETHアドレス + 金額 + ステータスによる注文の検索 |
| 6 | getContractInfo | マルチシグ情報を含む完全なコントラクト状態の取得 |
| 7 | getAvailableFees | 利用可能（予約されていない）手数料の取得 |
| 8 | getProposal | IDによる提案の詳細の取得 |
プロシージャ（状態変更）:
| ID | プロシージャ | 説明 |
|---|---|---|
| 1 | createOrder | ブリッジ注文（QubicからETH、またはETHからQubic）の作成 |
| 2 | completeOrder | マネージャーによる注文の完了（トークンの解放/ロック） |
| 3 | refundOrder | マネージャーによる注文の返金（トークンと手数料の返還） |
| 4 | transferToContract | ユーザーによるQubicからETHへの注文のためのトークン預け入れ |
| 5 | addLiquidity | マネージャー/管理者によるブリッジへの流動性の追加 |
| 6 | createProposal | マルチシグ管理者による管理提案の作成 |
| 7 | approveProposal | マルチシグ管理者による保留中の提案の承認 |
| 8 | cancelProposal | 提案作成者による保留中の提案のキャンセル |