​
0x0 Arcane Whitepaper

The Arcane Wallet is a next-generation cryptocurrency wallet designed to enhance privacy and security in digital transactions. Unlike traditional wallets, which expose user identities through public key addresses, the Arcane Wallet leverages advanced cryptographic techniques, such as stealth addresses and elliptic curve Diffie-Hellman (ECDH) key exchanges, to obscure transaction details and protect user privacy.

​
Key Features

  1. Stealth Addresses: Arcane Wallet generates unique stealth addresses for each transaction, ensuring that the recipient’s identity remains hidden on the blockchain. This feature prevents third parties from easily tracing transactions back to the recipient’s public key.
  2. Enhanced Privacy: By using ephemeral keys and shared secrets, the wallet ensures that only the intended recipient can recognize and access the transaction. This is achieved through the computation of view tags, which act as unique identifiers for transactions.
  3. Secure Key Management: The wallet supports both mnemonic phrases and private keys for secure key management, allowing users to recover their wallets easily while maintaining high security standards.

​
Comparison with Traditional Wallets

  • Privacy: Traditional wallets typically use static public key addresses, making it easier for observers to trace transactions and link them to specific users. In contrast, Arcane Wallet’s use of stealth addresses and view tags significantly enhances privacy by obscuring these links.
  • Security: While both Arcane Wallet and traditional wallets employ cryptographic techniques to secure funds, Arcane Wallet’s use of ECDH and ephemeral keys adds an additional layer of security, ensuring that transaction details remain confidential.
  • User Experience: Arcane Wallet offers a similar user experience to traditional wallets, with the added benefit of enhanced privacy features. Users can send and receive funds without needing to understand the underlying cryptographic processes, making it accessible to both novice and experienced users.
The Arcane Wallet represents a significant advancement in cryptocurrency wallet technology, offering enhanced privacy and security features that address the limitations of traditional wallets. By integrating cutting-edge cryptographic techniques, Arcane Wallet provides users with a secure and private way to manage their digital assets, setting a new standard for privacy-focused cryptocurrency solutions.

​
Moving assets Anonymously

In this setup, Bob wants to send an asset like ETH or an ERC20 token to Alice without revealing her wallet details. For this to happen, Alice provides her stealthAddress in the form 0x0<spk>.<vpk>, where spk represents the signing public key and vpk the viewing public key. This unique address enables Alice to receive assets anonymously. After Bob transfers the asset to Alice’s stealth address, Alice remains unaware of the transaction until Bob announces it. Bob must share key details that will help Alice locate and retrieve the transferred assets.

​
Required Announcement Details

Bob needs to provide Alice with the following data to identify the transaction:
  • Ephemeral Public Key: Used by Alice to compute a shared secret, confirming transaction authenticity.
  • View Tag: Alice matches this against computed tags to identify her transactions.
  • Token Address: Indicates the specific asset type Bob transferred to the stealth address.
To initiate a transaction, Bob uses Alice’s 0x0-address, containing her signing and viewing public keys. This process involves several cryptographic steps using elliptic curve cryptography.

​
Calculating the Shared Secret

The shared secret S\text{S} facilitates secure communication between Bob and Alice:
  1. An ephemeral key pair is created for the transaction.
  2. Using Elliptic Curve Diffie-Hellman (ECDH), the shared secret S\text{S} is calculated as:
S=ePrivK⋅vpk\text{S} = \text{ePrivK} \cdot \text{vpk} Where:
  • ePrivK\text{ePrivK} represents the ephemeral private key generated for the transaction.
  • vpk\text{vpk} is the recipient’s viewing public key.

​
Creating the View Tag

The view tag VT\text{VT} helps Alice efficiently identify her transactions:
  • VT\text{VT} is derived by hashing the shared secret S\text{S}:
VT=keccak256(S)\text{VT} = \text{keccak256}(\text{S})

​
Deriving the Stealth Public Key

The stealth public key stPK\text{stPK} is used to generate a unique address that only Alice can access:
  • stPK\text{stPK} is computed as:
stPK=spk+S⋅G\text{stPK} = \text{spk} + \text{S} \cdot \text{G} Where:
  • spk\text{spk} is Alice’s signing public key.
  • S\text{S} is the shared secret.
  • G\text{G} is the elliptic curve generator point.

​
Identifying Relevant Transactions for Wallets

Given that anonymous transactions are visible on the public blockchain, a wallet must determine its own transactions by analyzing specific broadcasted metadata (ePK\text{ePK}, VT\text{VT}):
  1. Derive a shared secret by performing an elliptic curve operation between the wallet’s viewing private key and the ephemeral public key ePK\text{ePK}, leveraging ECDH as previously described.
  2. Compute VT\text{VT} by applying a cryptographic hash to the derived shared secret.
  3. Compare the computed VT\text{VT} with the broadcasted transaction’s VT\text{VT}. A match confirms the transaction pertains to the wallet.

​
Accessing Privately Transferred Assets

After recognizing a transaction intended for her, Alice reconstructs the necessary private key to unlock the assets. This process relies solely on the ephemeral public key ePK\text{ePK}. The steps are as follows:
  1. Recalculate the shared secret using Alice’s viewing private key and the ephemeral public key ePK\text{ePK}.
  2. Derive the stealth private key stPrivK\text{stPrivK} by integrating the shared secret with Alice’s spending private key:
stPrivK=(spPrivK+S) mod n\text{stPrivK} = (\text{spPrivK} + S) \bmod n Where:
  • spPrivK\text{spPrivK} is Alice’s spending private key.
  • n\text{n} represents the order of the elliptic curve.
Once stPrivK\text{stPrivK} is derived, Alice can authenticate and retrieve the assets from the associated stealth address.
With the core operation of the wallet outlined, our next objective is to ensure seamless user interaction with funds while maintaining privacy. This extends to interacting with decentralized applications (DApps), such as executing token swaps on platforms like Uniswap, all while preserving the familiar experience of conventional transactions. To accomplish this, we developed a tailored contract that securely manages these operations while upholding user anonymity.

​
Arcane Contract

The Arcane Contract is a sophisticated smart contract designed to facilitate unlinkable and private transactions within the Arcane Wallet ecosystem. It leverages the stealth address protocol to ensure that transactions remain confidential and secure, providing users with enhanced privacy compared to traditional blockchain transactions. Consider a scenario where you hold 10 USDT and 5 USDT in separate stealth addresses. The contract enables you to send a total of 14 USDT to another 0x0 user in a single transaction.

​
Shielding Assets

This is the only transaction that would be publicly linked to your address. As it consists of you moving an asset like ETH or ERC20 from your public address into the Arcane Contract. During this transaction the asset is moved to a stealth address that your wallet controls.
There are two function that would enable this. For shielding ETH: 
/**
 * @notice Shield a token by transferring it to a stealth address
 * @dev The ETH sent to this function would be made only accessible to the receiver/stealthAddress
 *
 * Emits an {Announcement} event indicating the transfer
 *
 * @param _receiver The stealth address to transfer the token to
 * @param _announcementData The transfer announcement data
 */
function shieldETH(
    address _receiver,
    AnnouncementData calldata _announcementData
) external payable;
For shielding ERC20: 
/**
 * @notice Shield a token by transferring it to a stealth address
 * @dev The tokens sent to this function would be made only accessible to the receiver/stealthAddress
 *
 * Emits an {Announcement} event indicating the transfer
 *
 * @param _token The token to transfer
 * @param _receiver The stealth address to transfer the token to
 * @param _announcementData The transfer announcement data
 */
function shieldToken(
    address _token,
    address _receiver,
    uint256 _amount,
    AnnouncementData calldata _announcementData
) external;

​
Single Transfers

When you want to move the assets from a single stealth address to another or you want unshield you asset (in other words withdraw from the arcane contract) you’d call the transferFrom function: 
/**
 * @notice Transfer a ETH/ERC20
 * @dev Allows anyone to Withdraw and move their funds without needing
 * them to interact with the contract. Also this function can be used to transfer
 * funds from one stealth address to another
 *
 * Emits a {Transfer} event indicating the transfer
 *
 * Note: The _data parameter is used to call a callback function on the receiver
 * Also, every parameter should be verified by this contract (using _verify) so as to prevent
 * malicious contracts from stealing funds or mutating the parameters for personal gain.
 *
 * @param _token The token to transfer
 * @param _sender The stealth address to transfer the token from
 * @param _amount The amount of tokens to transfer
 * @param _receiver The stealth address to transfer the token to
 * @param _signature The signature of the sender
 * @param _transferData Extra parameters for the withdrawal
 * @param _announcementData The transfer announcement data
 */
function transferFrom(
    address _token,
    address _sender,
    uint256 _amount,
    address payable _receiver,
    Signature calldata _signature,
    TransferData calldata _transferData,
    AnnouncementData calldata _announcementData
) external;
You’d notice the _signature paramater, this signature is generated using the stealth address private key. Keep in mind the _sender is some stealth address.

​
Multiple Transfers

When you want to move the assets from a two or more stealth address to another stealth address or you want unshield the asset (in other words withdraw from the arcane contract) you’d call the transferFromMultiple function: 
/**
 * @notice Transfer from multiple stealth addresses
 * @dev Allows for a single transaction to transfer tokens from multiple stealth addresses.
 *
 * In a situation where a user has multiple stealth addresses with some token T and wants to
 * transfer a certain amount of T, but one stealth address does not have enough T to transfer,
 * the user can use this function to transfer the tokens from multiple stealth addresses.
 *
 * Emits a {Transfer} event indicating the transfer
 *
 * @param _token token to transfer
 * @param _senders an array of stealth addresses to transfer the token from
 * @param _amounts an array of amounts to transfer from each stealth address respectively
 * @param _totalAmount the total amount of tokens to transfer
 * @param _receiver the stealth address to transfer the token to
 * @param _signatures an array of signatures of the senders respectively
 * @param _transferData extra parameters for the transfer
 * @param _announcementData the transfer announcement data
 */
function transferFromMultiple(
    address _token,
    address[] calldata _senders,
    uint256[] calldata _amounts,
    uint256 _totalAmount,
    address payable _receiver,
    Signature[] calldata _signatures,
    TransferData calldata _transferData,
    AnnouncementData calldata _announcementData
) external;
You’d notice the _signatures paramater, this is a list of signature generated using the private keys of the _senders respectively.

​
Withdrawal or Unshielding

Looking at the transferFrom & transferFromMultiple functions you’d see a recurring parameter called _transferData this object contains a property called tType which signifies the transfer type, this can be either INTERNAL or EXTERNAL. External transfers tells the contract to unshield the asset being transfered and the address provided as the _receiver is assumed to be a non-stealth address.
To maintain privacy, we would need to use relayers, as initiating transactions directly from your wallet would reveal that you were the one who sent the transaction. Relayers send transactions on your behalf, ensuring they cannot be directly linked to your wallet. This adds an extra layer of privacy to your transactions.

​
Relayers

Relayers act as intermediaries, ensuring your transactions are seamlessly broadcasted to the network without requiring direct initiation from your wallet. They perform this service on your behalf and are compensated in the token being transacted.
To participate, relayer owners must maintain a minimum balance as specified in the Arcane Contract, which is a prerequisite for their creation and activation in the relaying process.

​
Fee Structure

Relayers form the backbone of the 0x0 ecosystem, serving as essential guardians of the network’s security. Operated by 0x0 token holders, these relayers are tasked with ensuring the seamless execution of transactions while covering their operational expenses and earning incentives. Upon the successful completion of a transaction, fees are allocated to the relayer responsible for its initiation, rewarding their contribution to the network’s efficiency. At the heart of this process is the calculation of the relayer fee for a given transaction Tx relayerFee=gasCost(TX)+0.1%×transaction amount\text{relayerFee} = \text{gasCost(TX)} + 0.1\% \times \text{transaction amount} This formula ensures that relayers are fairly compensated for both the computational resources expended and the value of the transaction processed.

​
Relayer Manager

The Relayer Manager is a critical component of the Arcane ecosystem, designed to facilitate and manage the operations of relayers within the network. Relayers play a vital role in ensuring the smooth execution of transactions. The Relayer Manager contract provides a robust framework for registering, activating, and managing relayers, ensuring that they meet specific requirements and adhere to the network’s security protocols.

​
Key Features

  1. Relayer Registration and Management: The contract allows for the registration of new relayers, ensuring that each relayer is associated with an owner and meets the necessary token balance requirements. This ensures that only qualified entities can act as relayers, maintaining the integrity of the network.
  2. Activation and Deactivation: Relayers can be activated or deactivated by their owners, providing flexibility in managing relayer availability. This feature is crucial for maintaining control over who can relay transactions and ensuring that inactive or compromised relayers are promptly deactivated.
  3. Security and Compliance: The contract includes several security checks, such as verifying relayer ownership and ensuring that relayers have sufficient token balances. These checks help prevent unauthorized access and ensure that relayers operate within the network’s guidelines.
  4. Event-Driven Architecture: The Relayer Manager emits various events, such as RelayerRegistered, RelayerActivated, and RelayerDeactivated, to provide transparency and traceability of relayer activities. These events help network participants monitor relayer status and ensure compliance with expected behaviors.
  5. Fee Management: The contract handles the collection and distribution of relayer fees, ensuring that relayers are compensated for their services. This includes support for fee swaps, allowing fees to be converted into different tokens if necessary.