Usability & Best Practices

This guide condenses the user-facing material from docs/USABILITY.md into a concise reference for people actually using ZEclipse-powered interfaces.

What ZEclipse Gives You

ZEclipse is designed to make private Solana transfers feel as close as possible to normal transfers while adding:

• 4-hop multi-path routing with millions of possible paths.
• Fake splits that act as decoys on-chain.
• Optional multi-wallet distribution so final funds land in several wallets.

The details (proof systems, hashes, timing strategies) are handled by the protocol and SDK.

Basic Workflow

Typical steps in a ZEclipse-enabled UI:

1. Connect a wallet (e.g., Phantom, Solflare).
2. Select “New Private Transfer”.
3. Enter the amount (e.g., 1 SOL).
4. Add recipient wallets:
   • Always at least 1.
   • Prefer 3–6 wallets for stronger privacy (your UI can help users create them).
5. Review costs and distribution:
   • Total amount and fees.
   • How much each wallet will receive (randomized proportions for obfuscation).
   • A simple privacy indicator or “score”.
6. Confirm & sign with the connected wallet.
7. Optionally watch progress as hops complete.

Multi-Wallet Distribution

Multi-wallet distribution is a core usability feature:

• Final amount is spread across 3–6 wallets.
• Randomized splits make it difficult for observers to know which wallets are “yours”.
• You can treat these as:
  • Separate “accounts” (savings, spending, cold storage).
  • Burn / decoy wallets depending on your threat model.

Best practices (from the usability docs):

• Avoid immediately recombining funds from different recipient wallets.
• Use different wallets at different times so they don’t look synchronized.
• Consider one-time or low-reuse wallets for high-sensitivity transfers.

Understanding Fees

In typical flows, you’ll see:

• Network fees – standard Solana transaction fees for each hop.
• Reserve – a small temporary reserve (e.g., ~2%) used as part of the privacy and account model.
• Service fee – a small fee to sustain the ZEclipse protocol.

Interfaces should:

• Show a clear breakdown before confirmation.
• Display an effective efficiency percent (e.g., ~98%).

See Core Concepts → Cost Efficiency for developer-side details.

Refunds & Failure Handling

If something goes wrong during a transfer:

• A refund mechanism returns most of the funds (e.g., ~95%) to the sender, keeping a small fee for processing.
• Refunds preserve privacy guarantees (you don’t “leak” more information during failure).

As a user:

• Wait a few minutes if a transfer looks stuck before triggering refunds.
• Make sure you have enough SOL to cover another attempt if you retry.

Troubleshooting

Common issues from the usability guide:

• Insufficient funds – ensure enough SOL for amount plus all fees and reserve.
• Slow or “stuck” transfers – temporal obfuscation adds delays; check your selected privacy level and wait the recommended window.
• Wallet connection problems – reconnect your wallet and refresh the page; state is tracked on-chain.

For app developers, also expose:

• Status monitoring endpoints or UI components.
• Helpful, non-leaky error messages (no raw stack traces).

Developer Tips

If you are building the UI on top of ZEclipse:

• Encourage multi-wallet usage and explain why it helps privacy in simple terms.
• Integrate the SDK and DApp connector instead of crafting transactions by hand.
• Provide:
  • Clear success / failure states.
  • Simple explanations of delays when high privacy levels are selected.
  • Pointers to this documentation for advanced users.

Remember: privacy depends on both technology and user behavior. Good UX should nudge users toward safer patterns without overwhelming them with cryptography.