# Horizen private ZEN wallet — mainnet E2E evidence

**Test date:** 7 September 2026  
**Live PoC:** https://horizenvew.kotavlabs.com/  
**Network:** Horizen Mainnet, chain ID `26514`  
**ZEN token:** `0x57da2D504bf8b83Ef304759d9f2648522D7a9280`  
**Vela processor:** `0x1e4ed21AbD8f56fF223A74BB0b85C46F1C52f7A2`  
**Application ID:** `6918290619433871739`

[Official Horizen mainnet RPC and explorer reference](https://docs.horizen.io/horizen-chain/api-reference/json-rpc/)

## Result

We completed a real-mainnet cycle with two independently created browser wallets:

1. Wallet A activated private receiving.
2. Wallet A approved and shielded `0.1 ZEN`.
3. Wallet B activated private receiving.
4. Wallet A sent `0.1 ZEN` privately to Wallet B.
5. Wallet B partially unshielded `0.04 ZEN`.
6. Wallet B claimed the `0.04 ZEN` publicly.
7. Wallet B retained `0.06 ZEN` in its private balance.

Final conservation check:

`0.9998 ZEN funded = 0.8998 public in A + 0.04 public in B + 0.06 private in B`

No ZEN was lost and no second shield was used to manufacture the final balance.

## Wallets

- **Wallet A:** `0x6E8c160153cd5aeCF8cb4a5f9b49d9571Abeb557`
- **Wallet B:** `0xD9d9Cb957Df8DEDC5B95cB463085cf0B79dC0e83`

Both wallets were created and restored independently. Wallet B's encrypted backup was opened by a separate local collector. The collector never signed or broadcast a mainnet transaction.

## Step-by-step evidence

### 1. Mainnet funding

Wallet A received `0.9998 ZEN` and Wallet B received `0.0001 ETH` for Horizen gas.

- [ZEN transfer to Wallet A](https://explorer.horizen.io/tx/0x16616bf0aeed11a89ffd8c3e4372aa2c3e57f1ac58ecfe0e7a1e89a61a3c24be)
- [Gas funding to Wallet B](https://explorer.horizen.io/tx/0x40673cd7e35ef8978d04f77368b3ccfdb3bafd2457800cdabe1f43709877eafd)

Recorded state: A public `0.9998 ZEN`; B public `0 ZEN`; private application custody `0 ZEN`.

### 2. Wallet A activated private receiving

- [Registration request](https://explorer.horizen.io/tx/0xe99e9d8786ec04ecabfb166481c5d4627c4e6c65390ab519ea3ba7e7ea25ec96)
- [Successful Vela completion](https://explorer.horizen.io/tx/0x73266682f8ce979d749696f7b13622e56350c3744182d09aac46aa9950214ce0)
- Request ID: `0x95d843c250957ecb144cf3462e0133d09f4f2bf2f967211d9ba8504d21a7776b`
- Completion: `status=0`, `errorCode=0`

This is a one-time registration for the wallet's private receiving key.

### 3. Wallet A shielded exactly 0.1 ZEN

- [Exact ZEN approval](https://explorer.horizen.io/tx/0xfbf40520571a6f83e78f59dbc4ebc36e6ceb219fc4fe440857eb24c6c07193c8)
- [Shield request](https://explorer.horizen.io/tx/0x48692c0611b44e72bc393582e56123dd188debaebe43f2fc327905bda258ca72)
- [Successful Vela completion](https://explorer.horizen.io/tx/0xc48d15c7d869e3d617ff7f6889527cad47eca79c589bf9a2f988fcda0ec38c1c)
- Request ID: `0x071fa1900f75937b22cf3acdfae1c0274488f8d9a024daca9307bf87d4b87735`

**Publicly visible:** Wallet A, processor address, ZEN contract and the exact `0.1 ZEN` transfer into custody. A's public balance changed from `0.9998` to `0.8998 ZEN`.

**Wallet state:** Wallet A displayed `0.1 ZEN` private after completion.

### 4. Wallet B activated private receiving

- [Registration request](https://explorer.horizen.io/tx/0xd7b122e105c9f29542d4ea17f63a3e9c36187ce2bf6816389aafb8d18b1bcc4f)
- [Successful Vela completion](https://explorer.horizen.io/tx/0x68baa13cc615f9028e44f939f751358d05beee32d652d6c306852d3b16643473)
- Request ID: `0x7334a318a0522b0fb3a915b190beb9b065f6325bd5e9a448a2309509d1cd2a43`
- Completion: `status=0`, `errorCode=0`

Wallet B's independently decrypted state reported `registered=true`, private balance `0` and zero private events before receiving the payment.

### 5. Wallet A sent 0.1 ZEN privately to Wallet B

- [Private-send request](https://explorer.horizen.io/tx/0x09eeed484a1970fc3d08142f82f75b5940ade97501e24fce32c9cff812ceca28)
- [Successful Vela completion](https://explorer.horizen.io/tx/0x130fa1a74b39bc28f57c4f91fa13a164c51317a4aaf43416685a6fea89e4bb4b)
- Request ID: `0x1f7d3411740c2d0165e24399f9bd537bce84a118e2e892d507f67d5e16bb5163`
- Submission: `00:45:11 UTC`
- Completion: `00:45:22 UTC`
- Completion: `status=0`, `errorCode=0`

**Publicly visible:** Wallet A submitted a request to the processor; transaction hash, timing, gas, the `0.000001 ETH` request value, request ID, completion transaction, state-root change and two encrypted `UserEvent` records.

**Not present in plaintext on the public transaction surface:** Wallet B's address and the `0.1 ZEN` amount. The submission and completion receipts contain zero ZEN `Transfer` events. A and B's public ZEN balances remained `0.8998` and `0` respectively, and custody remained `0.1 ZEN`.

**Wallet-local proof:** Wallet A changed from `0.1` to `0` private ZEN. Wallet B's independently decrypted state changed from `0` to `0.1 ZEN`, with its private event count changing from `0` to `1`.

### 6. Wallet B partially unshielded 0.04 ZEN

- [Unshield request](https://explorer.horizen.io/tx/0x963995e610bf9d2765dbcea3ffbc4c037acaba41fddfdfeb05b7d67eb58641a1)
- [Successful Vela completion](https://explorer.horizen.io/tx/0x14d13db3bececbe8913841bc27078102084883eac4911dc3948f8081a702472a)
- Request ID: `0x12d0c30c611c17de518b05f8ef3fa7dce593797b9c65c2647c0dae9b0d0ad848`
- Completion: `status=0`, `errorCode=0`

After completion, the public contract state reported `0.04 ZEN` claimable by Wallet B and `0.06 ZEN` remaining in the private application balance. Wallet B's independently decrypted state also reported exactly `0.06 ZEN` private and two private events.

### 7. Wallet B claimed 0.04 ZEN publicly

- [Public claim](https://explorer.horizen.io/tx/0xcf42851886f46206b2c75f89f58d47e69d5389caf2ee15c2af3aa189678e769a)

The receipt contains a public ZEN `Transfer` from the processor to Wallet B for exactly `40000000000000000` units (`0.04 ZEN`).

Final state:

| Balance | Wallet A | Wallet B |
|---|---:|---:|
| Public ZEN | 0.8998 | 0.04 |
| Private ZEN | 0 | 0.06 |
| Claimable ZEN | 0 | 0 |

Contract custody and private application accounting both equal `0.06 ZEN` after the claim.

## Public-chain visibility matrix

| Operation | Visible on Horizen mainnet | Not emitted in plaintext by the private-send flow |
|---|---|---|
| Activate | Sender, processor, request ID, timing, fee, completion | Wallet-local private balance |
| Shield | Sender, processor, token and exact amount | Resulting per-user private balance |
| Private send | Sender submitting the request, processor, timing, fee, request ID, encrypted events, completion and state-root change | Recipient address, transfer amount and per-user private balance changes |
| Unshield | Request sender, processor, timing, eventual claimable amount and destination | Remaining per-user private balance |
| Claim | Recipient and exact ZEN amount | Nothing about the claim itself; it is intentionally public |

The private-send claim above was checked directly against the raw transaction inputs and receipt logs. This demonstrates payload-level confidentiality on the public chain. It does not claim that a two-wallet scripted test provides a large anonymity set: timing and later public withdrawals can still support correlation.

## Reproducible evidence

The evidence collector uses the Horizen JSON-RPC endpoint and records canonical block hashes, timestamps, receipts, decoded events, public balances, custody totals and application state roots. Every JSON file has an adjacent SHA-256 checksum.

Key files and hashes:

- `wallet-a-activation-complete.json` — `4259f4fefa56cf5f7030f2675ace6aec455746002985e4adca7f527c61827d06`
- `wallet-a-shield-complete.json` — `4187bc725b8d87e5d4be4ccb5a080b310cc1bd5333a50226756f450bf51a7652`
- `wallet-b-activation-complete.json` — `b71c642d18dd3181afee5451beab81eeb518b8cfae231029394b1dd8527c44cb`
- `private-send-a-to-b-complete.json` — `ad96beb99979a970dae3bd2e899c0cd3ef0a267fd1c54305648520149697541c`
- `wallet-b-partial-unshield-complete.json` — `c5280f277c0f5cc5afedbeb35fa2b1d346e785769897129d9cfa93a74fcfa5f2`
- `wallet-b-claim-complete.json` — `0343580f9d526d1b9b64b1d7be09d0ce70d494a9ff0cc68e162070d44baa0a55`
- `private-send-visibility.json` — `b058d96d24724a0454cd07c2169b8a50c5369740411eff20d46a0e4552480220`

The independent Wallet B private-state captures produced these SHA-256 hashes:

- After activation, `0 ZEN`: `1da270c9ea1d96a2b92a66833c2a0e94e566d0f6d1bcbd442cc4d826479b7dd2`
- After private receipt, `0.1 ZEN`: `6bd5c6cb1b8a5bf7304016bc50b818f883b86628330bcea59758c563663bd40e`
- After partial unshield, `0.06 ZEN`: `2b69eab6fdac8e16eea41e1279c9e5a96d70ead04b0fb2fa54e0beaba6bc25a4`
- Final state, `0.06 ZEN`: `4b675ab78eace7e0d851f7c96a3a16a55265823302cf094f5db7a2bfc6f0c538`

The raw-visibility verifier passed all five assertions:

- Shield amount and route are public: **PASS**
- Private recipient absent from plaintext public surface: **PASS**
- Private amount absent from plaintext public surface: **PASS**
- No ZEN transfer during private send: **PASS**
- Claim amount and route are public: **PASS**

This PoC demonstrates the complete wallet UX and real-mainnet state transitions. A production deployment still requires the intended confidential execution environment, attestation, reviewed contracts and operational controls.