Cowrie Research

ginco

5 min read

Ginco

  • Name: Ginco

  • URL: https://www.ginco.co.jp/en

  • Category: wallet-management vendor / custody-workflow middleware company / cloud transaction-origination operator

  • Tags: custody wallets exchange-infrastructure japan

  • Summary: Ginco matters here as more than a generic wallet-software vendor. Its public business is enterprise crypto-asset wallet software for exchanges and other institutions, and Ginco’s own January 2025 incident disclosure drew the boundary in unusually useful terms: transaction-instruction and history servers plus user operation screens for Ginco Enterprise Wallet were served from Ginco-contracted cloud infrastructure, while customer-facing cold-wallet software was delivered for customers to run and control offline themselves. That split is exactly why Ginco deserves a company note. It lets the corpus preserve the real operator lesson from the DMM Bitcoin theft: even when a vendor says it does not custody customer assets or private keys, the vendor can still sit inside effective withdrawal authority if its infrastructure authors, routes, or mutates legitimate transaction requests before the final cold-wallet step.

  • What it does:

    • Develops and provides Ginco Enterprise Wallet, which Ginco markets as enterprise crypto-asset wallet software for exchanges and other institutional users
    • Provides business-use crypto-asset wallet systems, security-token custody systems, blockchain-utilization infrastructure, and related enterprise blockchain products according to its English company overview
    • Operates cloud-hosted transaction-instruction, transaction-history, and user-operation-screen infrastructure around the enterprise wallet workflow, as described in Ginco’s January 2025 incident disclosure
    • Delivers dedicated cold-wallet software to customers for offline storage, management, and use, while publicly saying Ginco itself does not store or manage customer crypto assets or private keys
    • Sits in the practical request-authoring and wallet-orchestration layer for customers using Ginco Enterprise Wallet, even when final custody hardware or cold-wallet operations are nominally customer-controlled

  • Key claims:

    • Ginco’s English company overview says the company develops and provides crypto-asset wallet systems for business use, security-token custody systems, and other blockchain infrastructure products
    • Ginco’s enterprise-wallet product page markets Ginco Enterprise Wallet as a high-share business wallet product for crypto-asset exchanges, emphasizes security and operational efficiency, and says the system can be embedded into customer systems and routed to customer-run nodes
    • The same product page says new platform currencies and ERC-20 tokens can be added on relatively short timelines, which is a useful reminder that Ginco is packaging operational wallet infrastructure rather than just publishing a reference implementation
    • Ginco’s January 2025 cyberattack disclosure says the servers that manage transaction instructions and history plus user operation screens were provided from Ginco-contracted cloud infrastructure, while customers stored and used the dedicated cold-wallet software offline themselves
    • The same disclosure says Ginco does not store or manage customer crypto assets or private keys and cannot operate the customer-side cold-wallet software, which is important because it separates Ginco’s formal non-custodial claim from the narrower but still critical request-authoring authority it retained
    • Ginco also disclosed that, in the DMM Bitcoin case, it provided the software to a separate company responsible for DMM’s system development and operations, preserving a three-layer operator map rather than a simple exchange versus wallet vendor story

  • Whitepaper: No standalone company whitepaper is the point here. The most useful primary materials are Ginco’s company / product pages plus its January 2025 incident disclosure because they describe the actual enterprise-wallet workflow boundary more concretely than abstract custody marketing does.

  • Sources:

Internal linkages

Protocol / company boundary

  • Ginco’s own disclosure preserves the split cleanly. Customer assets and private keys were supposed to remain under the customer’s control through dedicated cold-wallet software used offline.
  • This company note is about the layer above that: enterprise wallet software packaging, transaction-instruction and history servers, user operation screens, cloud infrastructure, and the request-routing / workflow surface that can still shape what the customer-side custody path eventually executes.
  • That distinction matters because the DMM Bitcoin incident did not require the strongest possible claim Ginco held the keys. The more reusable and more important lesson is narrower: a company can disclaim direct key custody and still remain inside effective withdrawal authority if its middleware can author or mutate legitimate requests.
  • Ginco is therefore useful as a company note precisely because it captures the middle layer many custody narratives blur away: not bare cold-wallet cryptography, not full exchange operations, but the enterprise-wallet workflow and cloud coordination surface between them.

Control surface

  • The important leverage sits in the transaction-instruction layer: the servers, user operation screens, and cloud workflow that define what request enters the customer-controlled cold-wallet path.

  • Ginco’s 2025 disclosure makes the asymmetry explicit. The cold-wallet software may be offline and customer-controlled, yet the surrounding enterprise workflow still lived on Ginco-contracted infrastructure and could therefore become the more practical compromise target.

  • That makes Ginco a strong operator-boundary note for the corpus. The company is not interesting because it contradicts its public we do not hold the keys claim in a simplistic way; it is interesting because the real custody boundary was wider than key possession alone.

  • In practice the useful audit question is: if Ginco’s cloud transaction-origination layer is compromised, what objective checks still prevent a customer-controlled cold-wallet process from authorizing the wrong destination, amount, or request class?

  • DMM Bitcoin showed why that question matters. A compromised vendor-side request path appears to have been able to append unauthorized data to a legitimate transaction instruction strongly enough that downstream operations still produced a catastrophic BTC transfer.

  • Last reviewed: 2026-07-25 UTC

Graph View

Backlinks