BOOSTRY Tech Blog

株式会社BOOSTRY の技術ブログです

トップ > ブロックチェーン > ERC-3009: Transfer With Authorization 調査

ERC-3009: Transfer With Authorization 調査

ブロックチェーン Ethereum EIP

ethereum.org

こんにちは。BOOSTRY CTO の麻生です。

本記事では、Ethereumのトークン規格の一つであるERC-3009についてご紹介します。本プロトコルを活用することにより、パブリックチェーンで課題となるガス代の扱いやトランザクション送信等に関して、金融機関が求める水準での柔軟性のあるソリューション提供が可能になると考えています。

eips.ethereum.org

本調査は B.O.O.S.T. Lab の活動の一環として行ったものです。調査内容は、2025/5/30 時点の情報となります。

1. 概要

1-1. 規格の概要

ERC-3009（Transfer With Authorization）は、ERC-20トークンにオフチェーン署名による転送認可を追加するための規格です。ユーザーがトランザクションに署名し、第三者や受取人がその署名を使ってトークン転送を実行できるため、いわゆる「ガス代不要（ガスレス）のトークン転送」や「メタトランザクション」を実現できます。ERC-3009を利用することで、以下のようなことが可能になります。

1-2. 他のERC規格との違い

ERC-3009と似た規格として、ERC-2612があります。

ERC-2612: Permit Extension for EIP-20 Signed Approvals

両者の主な違いは以下の2点です。

  • 直接転送 vs 承認パターン：ERC-2612はpermit関数によってトークンのallowance（承認額）設定を署名で認可し、その後に通常のtransferFromを行う仕組みです。一方、ERC-3009はトークンの直接移転を署名で認可します。これによりapprove/transferFromの二段階プロセスが不要となり、ワンステップでの転送が可能です。無限承認の濫用や複数回引き出し攻撃リスクも軽減できます。
  • ナンス管理：ERC-2612ではアカウントごとの連番ナンスを使用しますが、ERC-3009では各移転要求ごとに32バイトのランダムなユニークナンスを使用します。これにより複数の移転を並列実行しても衝突せず、未処理取引の混乱による失敗を防げます。

なお、EIP-3009の提案ではERC-2612と競合するものではなく、両方を実装しておくことで幅広いユースケースに対応できるとされています。ERC-3009はERC-20標準を拡張する形で後方互換性を保っており、ERC-777やERC-677といった他のトークン規格よりも既存エコシステムとの互換性を損なわない利点があります。

2. 技術仕様の詳細

2-1. 主な関数・イベント定義

ERC-3009では以下の関数とイベントが定義されています。

(Event) AuthorizationUsed
event AuthorizationUsed(
    address indexed authorizer,
    bytes32 indexed nonce
);

​ 特定の認証が使用された時に発行されるイベントです。

  • authorizer
    • 認証を行ったユーザーのアドレス
  • nonce
    • 認証に関連付けられた一意の値

後述するtransferWithAuthorizationやreceiveWithAuthorizationなどの関数実行時に発火します。

(Function) authorizationState
function authorizationState(
    address authorizer,
    bytes32 nonce
) external view returns (bool);

指定されたnonceが使用済みかを確認する関数です。

  • authorizer
    • 認証を行うユーザーのアドレス
  • nonce
    • 認証に関連付けられた一意の値

nonceが使用済みであればtrue、そうでなければfalseを返します。

(Function) transferWithAuthorization
function transferWithAuthorization(
    address from,
    address to,
    uint256 value,
    uint256 validAfter,
    uint256 validBefore,
    bytes32 nonce,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

オフチェーン署名によるトークン転送（以下、署名転送と呼びます）を実行するための関数です。

  • from
    • トークンを支払うユーザーのアドレス（認証者）
  • to
    • トークンを受け取るユーザーのアドレス
  • value
  • validAfter
    • この時刻以降に有効となる（unix time）
  • validBefore
    • この時刻以前に有効となる（unix time）
  • nonce
    • 一意の値
  • {v,r,s}
    • 署名パーツ

fromの署名{v,r,s}が有効であれば、コントラクトはfromのアカウントからtoへvalue分のトークンを移転します。validAfterおよびvalidBeforeで署名の有効期間を指定でき、現在時刻がこの範囲内のときのみ実行されます。この関数は誰でも呼び出せるため、リレーサービスや受取人が代理で呼び出すことも可能です。

(Function) receiveWithAuthorization
function receiveWithAuthorization(
    address from,
    address to,
    uint256 value,
    uint256 validAfter,
    uint256 validBefore,
    bytes32 nonce,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

こちらも署名済み転送を実行する関数ですが、受取人側で呼び出すことを想定しています。

  • from
    • トークンを支払うユーザーのアドレス（認証者）
  • to
    • トークンを受け取るユーザーのアドレス
  • value
  • validAfter
    • この時刻以降に有効となる（UNIX時間）
  • validBefore
    • この時刻以前に有効となる（UNIX時間）
  • nonce
    • 一意の値
  • {v,r,s}
    • 署名パーツ

transferWithAuthorizationとの違いは、コントラクト内でrequire(msg.sender == to)（関数呼び出し元が署名内のtoアドレスと一致すること）をチェックする点です。これにより、受取人以外はこの関数を実行できず、フロントラン攻撃（第三者が先回りして署名を使うこと）を防止できます。スマートコントラクトが署名移転を受け付ける場合は、こちらを利用することで安全に受領処理を組み込めます。

(その他) 固定値
// keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
bytes32 public constant TRANSFER_WITH_AUTHORIZATION_TYPEHASH = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267;

// keccak256("ReceiveWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
bytes32 public constant RECEIVE_WITH_AUTHORIZATION_TYPEHASH = 0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8;
  • TRANSFER_WITH_AUTHORIZATION_TYPEHASH
    • TransferWithAuthorization関数のための型ハッシュ値（keccak256）
  • RECEIVE_WITH_AUTHORIZATION_TYPEHASH
    • ReceiveWithAuthorization関数のための型ハッシュ値（keccak256）

どちらもEIP712（後述）に基づき、構造化データの署名に使用されます。

(その他) 【オプション機能】cancelAuthorization
event AuthorizationCanceled(
    address indexed authorizer,
    bytes32 indexed nonce
);

// keccak256("CancelAuthorization(address authorizer,bytes32 nonce)")
bytes32 public constant CANCEL_AUTHORIZATION_TYPEHASH = 0x158b0a9edf7a828aad02f63cd515c68ef2f50ba807396f6d12842833a1597429;

function cancelAuthorization(
    address authorizer,
    bytes32 nonce,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

署名された認証をキャンセルする関数です。authorizer（元の署名者）がこのキャンセル用メッセージに署名することで、対応する未使用のnonceを無効化できます。

キャンセルが実行されるとAuthorizationCanceledイベントが発行され、内部的にはそのnonceが使用済み扱いとして記録されます。万一、署名許可が漏洩した場合や有効期限内に処理を取りやめたい場合に備えた安全機能です。

2-2. EIP-712署名とデータ構造

EIP-712: Typed structured data hashing and signing

ここでは、ERC-3009の署名形式について解説します。ERC-3009は署名の形式としてEIP-712（Typed Structured Data Hash）規格に準拠しています。EIP-712を用いることで、署名メッセージに Domain Separator を含め、異なるコントラクトやネットワーク間で署名が再利用されることを防ぎます。主な仕組みは以下の通りです。

(1) Domain Separator

コントラクトごとに固有のドメインハッシュを定義します。一般に

keccak256(abi.encode(EIP712Domain(type), name, version, chainId, verifyingContract))

で計算され、

  • トークンの名前（name）
  • バージョン文字列（version）
  • チェーンID（chainId）
  • コントラクトアドレス（verifyingContract）

などを含めます。例えばUSDCでは、名前に"USD Coin"、バージョンに"2"（USDCコントラクトのv2を示す）を用い、チェーンID=1（Ethereumメインネット）とコントラクトアドレスを入れてドメインを構築しています。

bytes32 DomainSeparator = keccak256(abi.encode(
    keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
    keccak256("USD Coin"),       // name
    keccak256("2"),              // version
    1,                           // chainId
    0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48  // verifyingContract
));

​ このドメインセパレータはコントラクトデプロイ時に計算・保存され、全署名メッセージで共通して利用されます。

(2) TypeHash

署名許可ごとに固有のデータ構造（型）を定義します。ERC-3009では上述の通り、以下のTypeHash定数が規定されています。

TRANSFER_WITH_AUTHORIZATION_TYPEHASH

bytes32 TypeHash = keccak256(
  "TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)"
);
// Params := { From, To, Value, ValidAfter, ValidBefore, Nonce };

​ RECEIVE_WITH_AUTHORIZATION_TYPEHASH

bytes32 TypeHash = keccak256(
  "ReceiveWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)"
);
// Params := { From, To, Value, ValidAfter, ValidBefore, Nonce };

​ CANCEL_AUTHORIZATION_TYPEHASH（オプション）

bytes32 TypeHash = keccak256(
  "CancelAuthorization(address authorizer,bytes32 nonce)"
);
// Params := { Authorizer, Nonce };

実際の署名メッセージでは、これらTypeHashと具体的な引数値をABIエンコードしてハッシュ化した StructHash （構造体ハッシュ）を用います。たとえばtransferWithAuthorizationの場合、型TransferWithAuthorizationに含まれるフィールドfrom, to, value, validAfter, validBefore, nonce の入力値を順に並べてABIエンコードし、その keccak256 ハッシュ値を計算します。

bytes32 structHash = keccak256(abi.encode(
   TRANSFER_WITH_AUTHORIZATION_TYPEHASH,
   from,
   to,
   value,
   validAfter,
   validBefore,
   nonce
));

(3) ダイジェストの計算・署名

EIP-712に基づき、実際に署名されるメッセージハッシュ（ダイジェスト）は次のように計算します。

digest = Keccak256(0x19∥0x01∥ DomainSeparator∥ StructHash)

ここで 0x19|0x01 は固定のプレフィックス、DomainSeparatorは上述のドメインハッシュ、 StructHash は上述の構造体ハッシュです。

オフチェーンにて、クライアント（ウォレット等）がこのダイジェストに署名し、{v, r, s} 形式の署名値を得ます。

(4) 署名の検証

コントラクト側では、提供された{v, r, s}署名から署名者のアドレスを復元します。Solidityのecrecover関数を用いてecrecover(digest, v, r, s)を実行し、元の署名者アドレスを取得します。この値がfromパラメータ（移転元アドレス）と一致することを確認します。一致すれば署名が正当であるとみなし、後続の処理を実行します。この一連の検証により、署名が当該トークンコントラクト上でのみ有効かつ改ざんされていないことを保証しています。

2-3. ナンス管理とリプレイ攻撃防止

ERC-3009におけるナンス（nonce）は各転送要求を一意に識別する32バイトの値です。署名者（from）は転送要求ごとにランダムなナンスを生成し、署名メッセージに含めます。コントラクト側では、このナンスが使用済みかどうかを記録することで、同じ署名を二重に使うリプレイ攻撃を防ぎます。

transferWithAuthorization/receiveWithAuthorization 実行時には、まず指定されたnonceが未使用であることを確認します。未使用であれば処理を進め、成功時にそのnonceを使用済みにセットし、AuthorizationUsedイベントを発行します。これにより、同一署名（同一nonce）による二重実行ができなくなります。仮に悪意ある第三者がトランザクションを複製提出した場合でも、先に1つが承認されればナンスが使用済みになり、2つ目以降はauthorizationStateチェックで弾かれて失敗します。

ランダムナンスは順序性を意識する必要がなくなる利点がある一方で、複数の転送要求を一度に発行すると、実行順序は Relayer や Miner に委ねられる点には注意が必要です。互いに依存関係のあるトランザクションを同時投入すると順序次第で失敗しうるため、その場合は一つずつ順番に処理すべきです。

2-4. 有効期間（validAfter / validBefore）

各トランザクションには有効開始時刻(validAfter)と有効期限(validBefore)を設定できます。コントラクトは現在のブロック時刻（block.timestamp）がこの期間内にあることを確認してから転送を実行します。具体的には、now >= validAfterかつnow < validBeforeであることをコントラクトのレイヤでチェックします。これにより、ユーザーは署名の有効タイミングを細かく制御できます。

有効期間のチェックにより、署名が古くなってから不正に再利用されることも防げます（期限切れ後の署名は受理しません）。この仕組みはERC-2612のpermitのdeadlineと似ていますが、ERC-3009では開始時刻も指定可能な点でより柔軟です。

2-5. セキュリティ上の考慮事項

ERC-3009は署名転送の安全性を確保するため、いくつかの対策が組み込まれています。 上述したものと内容面で重複している部分もありますが、以下の点で安全性の向上が行われています。

(1) チェーン間リプレイ防止

上述の通り DomainSeparator にchainIdやコントラクトアドレスが含まれているため、署名は特定のチェーン上の特定コントラクトでしか有効になりません。仮に同じ署名データを他ネットワークや別コントラクトで利用しようとしても、ドメイン不一致で実行時エラーとなります。

(2) フロントラン攻撃への対策

署名データはブロードキャストされると誰でも利用可能になるため、第三者による先行実行（フロントラン）に注意が必要です。トークンコントラクトとは別の、あるスマートコントラクトBがユーザーから署名を受け取り、内部でtransferWithAuthorizationを呼んでトークンの受け入れを行うような場合を考えます。悪意あるアドレスCがトランザクションプールに存在するその署名を取得し、コントラクトBよりも先に直接トークンコントラクトに対してtransferWithAuthorizationを呼んでしまうと、トークンはBに送金されるものの、コントラクトB側の処理が行われずに預け入れが宙に浮くなどの危険があります。こうした攻撃を防ぐため、受取人自身しか実行できないreceiveWithAuthorization関数が用意されています。コントラクトBはこの関数を使うことで、自分自身（受取人）からの呼び出しでしか署名転送が成立しないようにでき、上記のような不整合を回避できます。さらに、もし同一コントラクト内で複数種類の署名受取関数を実装する場合、Nonceの先頭バイトに機能識別子を埋め込むなどして署名の使い回しを機能間で防ぐ工夫も考えられます。

(3) キャンセル機能

オプション機能であるcancelAuthorization関数は、万が一署名が漏洩した場合や有効期限前に取り消したい場合に、後出しの署名で先の署名を無効化できる手段です。このキャンセルもEIP-712署名を用いて行われ、正当な所有者のみが自身のナンスを無効化できます。キャンセル実行後はAuthorizationCanceledイベントが発行され、該当ナンスは使用済みとなるため元の転送要求は通らなくなります。なお、一度移転が実行されてしまった署名は既にナンスが使われているため二重行使は不可能であり、キャンセルはあくまで未行使の許可に対してのみ有効です。

(4) ERC-20承認パターンの脆弱性回避

前述の通り、ERC-3009は approve/transferFrom パターンを用いないため、従来ERC-20で問題となっていた「複数回引き出し攻撃」や、常時最大値を承認しておくアンチパターン（無限承認）による被害を防ぐことができます。各トランザクションが独立したユーザー署名に紐づくため、意図しない資金流出リスクを低減できます。

3. Solidityでのサンプル実装コード

開発者がERC-3009をトークンコントラクトに実装する際の最小構成の一例をご紹介します。既存のERC-20実装（例えばOpenZeppelinのERC20）に対し、「DomainSeparator」「署名検証ロジック」「ナンス管理」を追加する形になります。以下に、ERC20トークンにERC-3009の主要機能を組み込んだ簡易実装例を示します（エラー処理メッセージ等は簡略化しています）。

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract AuthTransferToken is ERC20 {
    // EIP-712 Domain 用定数
    bytes32 public DOMAIN_SEPARATOR;
    bytes32 public constant TRANSFER_WITH_AUTHORIZATION_TYPEHASH = 
        keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)");
    bytes32 public constant RECEIVE_WITH_AUTHORIZATION_TYPEHASH = 
        keccak256("ReceiveWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)");

    // 認可Nonceの使用状況管理マッピング
    mapping(address => mapping(bytes32 => bool)) public usedNonces;

    // イベント（AuthorizationCanceledは省略）
    event AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce);

    constructor(string memory name, string memory symbol) ERC20(name, symbol) {
        // EIP-712 Domain Separator を構築（チェーンIDも含む）
        uint256 chainID;
        assembly { chainID := chainid() }  // 現在のチェーンIDを取得
        DOMAIN_SEPARATOR = keccak256(abi.encode(
            // EIP712 Domain の TypeHash
            keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
            // トークン名
            keccak256(bytes(name)),
            // バージョン（例として"1"を使用）
            keccak256(bytes("1")),
            // チェーンID
            chainID,
            // コントラクトアドレス
            address(this)
        ));
    }

    /**
     * @dev 署名付トークン移転（誰でも呼び出しが可能）
     */
    function transferWithAuthorization(
        address from,
        address to,
        uint256 value,
        uint256 validAfter,
        uint256 validBefore,
        bytes32 nonce,
        uint8 v, bytes32 r, bytes32 s
    ) external {
        require(block.timestamp >= validAfter, "Auth: not yet valid");
        require(block.timestamp <= validBefore, "Auth: expired");
        require(!usedNonces[from][nonce], "Auth: nonce already used");

        // EIP-712メッセージの structHash を計算
        bytes32 structHash = keccak256(abi.encode(
            TRANSFER_WITH_AUTHORIZATION_TYPEHASH,
            from, to, value, validAfter, validBefore, nonce
        ));
        // 署名ダイジェストの計算（0x1901 + DomainSeparator + structHash）
        bytes32 digest = keccak256(abi.encodePacked("\x19\x01", DOMAIN_SEPARATOR, structHash));
        // ecrecoverで署名者を復元
        address recoveredAddress = ecrecover(digest, v, r, s);
        require(recoveredAddress == from, "Auth: invalid signature");
        require(recoveredAddress != address(0), "Auth: invalid sig (zero)");

        // Nonceを使用済みにマークし、イベント発行
        usedNonces[from][nonce] = true;
        emit AuthorizationUsed(from, nonce);

        // ERC-20転送実行（内部的にbalance更新とTransferイベント発行）
        _transfer(from, to, value);
    }

上記コードでは、ERC20トークン（ERC20(name, symbol)を継承）の基本機能に、ERC-3009の署名転送機能を追加しています。実装のポイントを補足します。

Domain Separator の設定

コンストラクタでDOMAIN_SEPARATORを計算・設定します。トークン名・バージョン・チェーンID・コントラクトアドレスを含めたEIP712ドメイン情報をKeccak256ハッシュ化しており、これが署名ダイジェスト計算時に使用されます（\x19\x01 || DOMAIN_SEPARATOR || structHash）。

サンプルではバージョンに"1"を直書きしていますが、実際にはトークンのバージョン管理戦略に応じて適切な値を用いてください。チェーンID取得にはSolidity 0.8.0以降の組み込みblock.chainidや上記のようなassemblyによるchainid()命令が利用できます。

TypeHash 定数と Nonce 管理

コントラクト内にTRANSFER_WITH_AUTHORIZATION_TYPEHASH等の定数を定義し、またusedNoncesマッピングでNonceの使用履歴を管理しています。usedNonces[from][nonce]がtrueの場合、その組み合わせの署名は既に使われた（またはキャンセル済みである）ことを示します。コード中では関数実行時にrequire(!usedNonces[from][nonce])で未使用チェックを行い、成功時にusedNonces[from][nonce] = trueとして再利用不可にしています。

transferWithAuthorization の実装

提供されたパラメータと署名を検証し、正しければトークン転送を実行します。手順は以下の通りです。

  1. 現在時刻がvalidAfter～validBeforeの範囲内か検証し、有効期間外なら拒否
  2. Nonceが未使用であることを確認
  3. structHashとダイジェストを計算
  4. ecrecoverで署名者を復元し、一致性をチェック
  5. Nonceを使用済みに記録し、イベントAuthorizationUsedを発行
  6. 内部的に_transfer(from, to, value)を呼んでERC-20トークン転送処理を行う

署名者の復元では、require(recoveredAddress == from)で署名が確かにfrom本人のものであることを確認し、加えてrecoveredAddress != address(0)で署名が有効形式であることも保証しています。

receiveWithAuthorization の実装

大部分はtransferWithAuthorizationと同様ですが、先頭でrequire(msg.sender == to)を行っている点が異なります。これにより、関数呼び出し者が受取人アドレスでない場合に即座に失敗します。

このように、ERC-3009の実装はERC-20トークンコントラクトに比較的容易に組み込むことができます。OpenZeppelinには現時点で公式なERC-3009実装は含まれていませんが、USDCの実装例や上記のような参考コードを基に、自前で拡張機能を追加することができます。

4. ERC-3009を採用している主なトークンプロジェクト例

ERC-3009は2020年に提案され、以降主要なステーブルコインを中心に採用例が増えています。代表的なプロジェクトと、その採用理由をご紹介します。

USD Coin (USDC)

Recibo: Encrypted Messages for ERC-20 Transactions

時価総額の大きい米ドル連動ステーブルコインUSDCは、バージョン2へのアップグレード（2020年後半）でERC-3009を導入しました。USDC v2スマートコントラクトにはtransferWithAuthorizationおよびEIP-2612 (permit)が実装されており、Circle社はこれによりユーザビリティとセキュリティの向上を図っています。USDCがERC-3009を採用した主な理由は、ガス代の問題を緩和してユーザーエクスペリエンスを改善するためです。USDC利用者は銀行送金感覚でトークンを扱うことが期待されるため、ETHを持っていなくてもUSDCを送金できるメカニズム（ガスレス送金）は非常に有用でした。また、DeFi領域でもUSDCの単一トランザクションでの許可と転送のアトミック実行（許可→転送の2段階を不要化）が可能となり、コントラクト間の統合が容易になりました。

Paxos社のステーブルコイン群（USDP, PYUSDなど）

paxosglobal/paxos-token-contracts

規制準拠のステーブルコインを発行するPaxos社も、自社トークンにERC-3009を実装しています。例えば Pax Dollar（USDP、旧称PAX）や PayPal USD（PYUSD）といったトークンのコントラクトでは、ERC-3009のtransferWithAuthorizationおよび独自拡張のtransferWithAuthorizationBatch（複数転送のバッチ版）を備えています。Paxos社がERC-3009を採用した目的もやはりガスレス取引の提供であり、「ユーザーが署名によって第三者（デリゲート）にトークン移転を許可し、その第三者がガス代を負担して転送を代理実行できる」ようにするためです。特にPYUSDはPayPalという決済大手が関与するステーブルコインであり、幅広いユーザー層に配慮してスムーズな送金体験を提供する必要があります。

Paxos系トークンはUSDCと同様にEIP-2612 (permit)も実装しており、承認（permit）と転送（transferWithAuthorization）の両面でメタトランザクション対応を完備しています。これにより、DeFiやCeFi問わず統合しやすさに繋がり、採用の追い風となっています。

5. まとめ

本記事では、ERC-3009規格の背景、技術仕様、Solidityでの実装例、及び主要な採用事例について解説しました。ERC-3009はオフチェーン署名によるトークン移転を可能にし、ガスレス送金やユーザビリティ向上に寄与する有力な規格です。特にUSDCやPaxos系ステーブルコインなど、実需の大きいトークンでの採用が進んでおり、その有用性が実証されつつあります。

また、ERC-3009で採用されているEIP-712署名形式は、様々なメタトランザクションの規格に応用可能です。弊社BOOSTRYでも、ERC-3009をベースにした独自のメタトランザクションソリューションを開発しており、これらの情報についても今後発信していく予定です。

なお、本記事の内容は社内勉強会資料をもとに再整理したものです。BOOSTRYでは毎週、社内で技術勉強会を開催し、ブロックチェーンをはじめとする先端技術の知見をメンバー間で共有しています。この記事を通じて、BOOSTRYの技術への取り組みやブロックチェーン技術の可能性に少しでも興味を持っていただければ幸いです。今後も研究開発およびプロダクト開発を通じて、より効率的で機能性の高い、先進的な金融市場の実現に向けて取り組んでまいります。引き続きBOOSTRYの活動にご注目ください。

ご興味のある方は、ぜひ採用情報もご覧ください。私たちは、金融×ブロックチェーンという難しくもやりがいのある領域で、新しい市場を共に創る仲間をいつでも歓迎しています。

〒101-0032 東京都千代田区岩本町3丁目9-2 PMO岩本町4F