Direct Address (DA)
Last updated
Was this helpful?
Last updated
Was this helpful?
"Direct Addresses" are derived from a user's wallet key in a deterministic fashion (refer to image below).
Each user starts with an ECDSA private key. DeGate is not able to access the raw L0PriKey.
DeGate requests a signature on a fixed message, such as “DeGate: V1 Nonce:1” by using L0PriKey. This ensures uniqueness per user and per key reset.
The wallet responds with an ECDSA signature, which DeGate labels as L0Signature.
DeGate’s front-end (or core code) hashes the L0Signature to create a seed.
This seed is converted into a mnemonic phrase according to BIP39, a widely used standard in the crypto space (often recognized by 12–24 human-readable words).
BIP44 is a framework for hierarchical deterministic wallets, allowing different derivation paths for different blockchains.
Using the mnemonic, the user’s browser front-end derives direct address private keys (DAPrivKeys). Each chain (e.g., Solana, Base) may have its own path or curve requirements, but the concept remains the same: the user now has a private key for each extended chain that is cryptographically tied back to user's original wallet.
DeGate provides easy UI hooks so users do not have to manage multiple mnemonics or do the derivations manually
Each direct address belongs exclusively to the user. If the user requests to swap USDC for SOL, the “direct address” on Solana receives the tokens. Since only the user’s private key can authorize transactions from that address, DeGate (or any other external party) remains incapable of unilaterally moving the user’s funds.
Direct addresses keys offer the same level of security as asset keys.
The DeGate protocol and degate.com do not and cannot access users’ wallet private keys.
Direct address keys are temporarily stored in the browser’s local SessionStorage and are automatically cleared when the browser tab is closed. SessionStorage does not support cross-domain or cross-session access, which makes it secure.
DeGate has implemented a front-end security isolation strategy by splitting the front-end into "wallet codes" and "trade codes". The wallet and trade codes are isolated: wallet code handles the signature mechanism within an iframe, while trade code executes in a sandboxed environment, ensuring the keys and signatures are secure and inaccessible from the trade side. In the future, the core front-end code will be deployed on decentralized platforms to make it immutable, further enhancing private key security. For more info on secret keys and signatures, do visit
