Account-Based Privacy: The Unprecedented Combination

What Problem Does This Solve?

The Challenge:

Blockchain needs:
  ✓ Account simplicity
  ✓ Privacy guarantees
  ✓ Smart contract support
  ✓ Direct account updates
  
But historically:
  ❌ Accounts = No privacy
  ❌ Privacy = Output-based only
  ❌ Can't have both... or can we?

DERO's Solution:

• ✅ Account-based model (simple, fast)
• ✅ Homomorphic encryption (privacy)
• ✅ Private smart contracts (unique to DERO)
• ✅ Best of both worlds

The Account Model Advantage

How DERO's Accounts Work

Account Structure:

• Balance is a single value that can be directly updated
• Direct query - no need to sum outputs
• Simple add/subtract operations
• Natural fit for smart contracts
• Lower complexity than output-based systems

Why Account + Privacy Is Hard

The Challenge DERO Solved

The Impossible Problem:

Why This Was Thought Impossible:

For accounts with privacy:
  1. Balance must be encrypted
  2. Operations must work on encrypted values
  3. Network must verify without decrypting
  4. Updates must be direct
  5. Must support smart contracts

The problem:
  ❌ How to add E(old) + E(new)?
  ❌ How to verify E(balance) >= E(amount)?
  ❌ How to update encrypted balance ciphertexts?
  ❌ How to do this efficiently?

Most blockchains: CANNOT solve this

Three Key Advantages

1. Transaction Confirmation (Target Block Time)

DERO's Flow: Submit to mini-block system → account update → main block target time (BLOCK_TIME = 18s)

Advantage: Fast confirmation with account model + privacy ✅

2. Simple Balance Checking

DERO's Flow: Query encrypted balance → decrypt with private key (no chain scanning)

Advantage: Balance checks without full sync ✅

3. Smart Contract Compatibility

DERO Account Model: Natural state storage, direct balance updates, contracts can move encrypted wallet balances homomorphically without seeing the amount

Advantage: Rich smart contracts whose token movements preserve user privacy (contract logic and state itself are public).

Technical Implementation

How DERO Manages Encrypted Accounts

Account Structure:

• Address: dero1qy...
• Encrypted balances stored in Graviton DB
• Key: the compressed public key (33 bytes — tx.MinerAddress[:] or the pubkey decoded from the bech32 address); the dero1qy... bech32 form is only the display encoding. Value: E(amount) (ElGamal (Left, Right) pair)
• Supports multiple assets: DERO, tokens, etc.

Balance Updates:

Simplified pseudocode (blockchain/transaction_execute.go):

// Conceptual flow — see source for actual implementation
func UpdateBalance(address, amount):
    old_encrypted := LoadBalance(address)  // E(old)
    new_encrypted := HomomorphicAdd(old_encrypted, amount)  // E(old + amount)
    StoreBalance(address, new_encrypted)  // Save E(new)
    
// Network never decrypts old, amount, or new!

Mini-Blocks and Finality

How DERO Achieves Fast Confirmation

Mini-Block Architecture:

Timeline:

Why This Works:

• Single account validation (simple)
• Easy parallelization
• Fast confirmation
• Privacy maintained throughout

DERO combines: Speed of accounts + Privacy of encryption ✅

Wallet Synchronization

Lightweight Clients Possible

DERO Account-Based: Query encrypted balance to Decrypt with private key = Seconds (optional history sync)

Advantage: Lightweight wallets with full privacy ✅

Privacy Guarantees

What Account Model Doesn't Compromise

Result: Strong privacy guarantees on transfers and balances; contract logic is openly auditable.

What a verified DERO-PROOF reveals

The privacy guarantees above are the defaults — what the chain hides from every observer. DERO also gives the sender a per-transaction escape hatch: the DERO-PROOF (a.k.a. DERO proof or transaction proof elsewhere in these docs — same thing, single canonical wire-format string). By sharing the proof string for one specific transaction, the sender lets a verifier confirm what was sent to whom — on-chain equivalent of handing someone a receipt.

A verified DERO-PROOF on the public explorer surfaces exactly three fields:

The proof scheme is sender-driven: the sender holds the tx key, runs the proof tool, and hands the resulting string to whoever needs to verify the payment. The verifier resolves it against the on-chain transaction; the chain confirms that the named receiver was paid the named amount.

Source: proof/proof.go (Prove() returns receivers, amounts, payload_raw, payload_decoded); cmd/explorer/explorerlib/explorerlib.go wires the result into the explorer UI; cmd/explorer/explorerlib/templates/tx.tmpl renders the verified-proof block as {receiver} Received {amount} DERO.

Note: scope is one transaction at a time. A proof for tx-A reveals nothing about tx-B, even between the same parties.

Why DERO's Approach Works

The Account Model Advantage

DERO proved: You CAN have account simplicity AND privacy!

What Makes DERO Unique

Key Takeaways

What Account-Based Privacy Provides

What It Enables

• ✅ Private Smart Contracts - Unique to DERO
• ✅ Encrypted Balance Queries - No blockchain scanning
• ✅ Lightweight Wallets - No chain scanning required
• ✅ Target Block Time - 18 seconds
• ✅ Account Simplicity - Lower complexity
• ✅ Proven in Production - Working system, not theoretical

Related Pages

Privacy Suite:

• Ring Signatures - Transaction anonymity
• Homomorphic Encryption - Balance privacy
• Transaction Privacy - Complete privacy model

Technical:

• DERO Wallets - Stealth address generation
• Wallet RPC API - Integrated addresses

Understanding DERO:

• DERO Tokens - Account-based asset model
• Privacy Features - Full privacy suite overview