Yeah, I gave up because of my little free time, but I really hope I’ll have a chance to contribute to feature net… See you next week!
No, I’m too tired today…
Sorry, next time, have a nice worskhop!
Thanks to everyone who joined this week’s Crosslink Workshop. If you couldn’t make it, you can watch the recording here:
Also, @zk_nd3r provides a walkthrough of cTAZ, a platform that gives users visibility into network health and activity.
Important: The deadline to submit your Crosslink UFVK and mainnet Orchard address for Round 1 feature net payouts is Wednesday, June 17 at 11:59 PM UTC. Please send them to me via Signal or on the Forum.
Note: If you staked using both the desktop and mobile wallets, you must send both UFVKs.
@aquietinvestor Here is my Round 1 reward submission:
Feature Net UFVK (Desktop Node):
uviewtest1zpuw85dm3ugzyj2dqfkuxt08cyzzk9h0vemjuy3e7d95u8ra0jcn7s9x6eu85zyq0x0xpj4fnkfcxpgctmwl365s77njxy3d8vs6hy80czkal3and9ze40flu03dau5llzrsgcxreh03a4epmg5tu8v7tydaf20y4s0nm9mhzfyne6ap5tygkvsxsketxmya4cqlthm68dpjax75txdgw0cerlke6mdsunn60xsy00w2tlxwrm3agqk576s6u39fzkkych87xu40pulmx2qdjqr8elj6ln5ualzlamzrh3ztkpfzxz8ql57tny3pstvy5t6xrsunlmznavdhg0hr88e7p0etzyn8s6w99lwv8tk7u7930q4d2pjl5t76ymxr4r3qxfx0s0pjdwq7zh7z3wdax78ghgl3mpj6d82egytjzhllv428uj55dfa0m7fen99je779277qz5lpjsa4z6mxccs7f4g2s7u03nu6tmhcjpnpzug7guqp
Feature Net UFVK (Mobile Wallet - Delegation):
uviewtest10wzqa5ydnc5cx553hq0tk7lvvzd7j6laqld0vcztnxjsp780rdpl73je6k9mxjecgxhc2yarrstw2fq0rr6frym3p6vl2gkeg586d6wwpwflsz9wnak3uy6cs9x7r6mh3vu2crpy5c8dtrvlevfpsqx2wny8mtffvtzzmqc3esjndw5z557tlql3nqy73x4983peswsd660qjqq4q99tzqtad5qr3qjammmdp26uthmyfj7wuly8rjtpwyaz8zlxkt6v6zdd5lcq7ggh604aapn3vux042ydpjhh6mg2j8ctdlxm5f5cfqzc0mcaucr76asw88ashyuvm7are3avg70hvk77xukw9q793h3q620c3uy85hwlzezwdayrrujeshla48k248dts974vjzfw0h3a07hmdqe0u22rg9sce3m2exa5k88w0pptylnd6ncc7dn3yfstfah3ac6jnzvjau77cw6k6lq080d7fhu6sd6nns59crwdf7k
Mainnet Orchard Address:
u156x5ay438e8wzmpcm5sztwcm0qndaawrr5039c4xs2ec60pdcw878hrdapm5m0vgzg9r8a6yy9jvlmk0gsxw3yqg2c2wrf4l352qcnsu
Thank you!
Round 1 payouts were distributed this week, with the full 25 ZEC reward pool allocated. A total of 11.2 ZEC was distributed as non-discretionary rewards based on the amount of cTAZ earned through mining and staking during Round 1. In total, 22 received rewards.
The average payout was 0.51 ZEC, with a median payout of 0.053 ZEC. The largest reward was 6.598 ZEC, with the remaining rewards distributed among the other participants.
Not all eligible participants submitted viewing keys during the claim window, leaving 13.8 ZEC unallocated. Those funds were distributed as discretionary rewards to recognize participants who made significant contributions to the Feature Net during Round 1.
Community Contributors: Our MVP Community Contributors are @zk_nd3r and @Kenbak who developed block explorers, visualization tools, analytics, and other resources that made it significantly easier for everyone to monitor and understand the network.
Active Participants: @dismad, @ssh, @Jiggytom and @treasonous received discretionary rewards for actively testing the network, reporting issues, participating in discussions, and helping keep the Feature Net community active and engaged.
Thank you to everyone who participated in Round 1. We know the experience hasn’t been smooth with BFT finality stalled and participants ending up on different chains, but we expect many of these issues to improve as the network and tooling mature. We’re currently targeting mid-July for the user-led forking tool, which should help us get BFT finality unstalled and running again.
As we continue through Round 2, we’d love to see even more people get involved. The best way to help is to use the network, share your experience, and let us know what’s working well and what could be improved. If you encounter bugs, please report them with as much detail as possible, including logs. We’d also love to hear your ideas for improving the user experience. Your participation will help us improve Crosslink faster.
Hi Crosslink team,
I’m writing to kindly ask you to re-check my Round 1 reward submission.
From the beginning of Round 1, I participated in the Crosslink Feature Net and followed the instructions to submit my Feature Net viewing keys and my mainnet Orchard address before the deadline.
I submitted my reward details on the forum in post #48 on June 17, 2026 at 09:21 UTC, before the June 17, 2026 23:59 UTC deadline.
I submitted both UFVKs because I used both desktop and mobile wallets.
Desktop UFVK:
uviewtest1zpuw85dm3ugzyj2dqfkuxt08cyzzk9h0vemjuy3e7d95u8ra0jcn7s9x6eu85zyq0x0xpj4fnkfcxpgctmwl365s77njxy3d8vs6hy80czkal3and9ze40flu03dau5llzrsgcxreh03a4epmg5tu8v7tydaf20y4s0nm9mhzfyne6ap5tygkvsxsketxmya4cqlthm68dpjax75txdgw0cerlke6mdsunn60xsy00w2tlxwrm3agqk576s6u39fzkkych87xu40pulmx2qdjqr8elj6ln5ualzlamzrh3ztkpfzxz8ql57tny3pstvy5t6xrsunlmznavdhg0hr88e7p0etzyn8s6w99lwv8tk7u7930q4d2pjl5t76ymxr4r3qxfx0s0pjdwq7zh7z3wdax78ghgl3mpj6d82egytjzhllv428uj55dfa0m7fen99je779277qz5lpjsa4z6mxccs7f4g2s7u03nu6tmhcjpnpzug7guqp
Mobile UFVK:
uviewtest10wzqa5ydnc5cx553hq0tk7lvvzd7j6laqld0vcztnxjsp780rdpl73je6k9mxjecgxhc2yarrstw2fq0rr6frym3p6vl2gkeg586d6wwpwflsz9wnak3uy6cs9x7r6mh3vu2crpy5c8dtrvlevfpsqx2wny8mtffvtzzmqc3esjndw5z557tlql3nqy73x4983peswsd660qjqq4q99tzqtad5qr3qjammmdp26uthmyfj7wuly8rjtpwyaz8zlxkt6v6zdd5lcq7ggh604aapn3vux042ydpjhh6mg2j8ctdlxm5f5cfqzc0mcaucr76asw88ashyuvm7are3avg70hvk77xukw9q793h3q620c3uy85hwlzezwdayrrujeshla48k248dts974vjzfw0h3a07hmdqe0u22rg9sce3m2exa5k88w0pptylnd6ncc7dn3yfstfah3ac6jnzvjau77cw6k6lq080d7fhu6sd6nns59crwdf7k
Mainnet Orchard address:
u156x5ay438e8wzmpcm5sztwcm0qndaawrr5039c4xs2ec60pdcw878hrdapm5m0vgzg9r8a6yy9jvlmk0gsxw3yqg2c2wrf4l352qcnsu
My desktop UFVK still matches the viewing key copied from my current Crosslink app, and the mainnet Orchard address is valid. However, I have not received any Round 1 ZEC payout in my wallet.
Could you please confirm:
- whether both my Desktop and Mobile UFVKs were included in your Round 1 scan;
- the cTAZ earned total detected for each UFVK;
- whether a payout was generated for my Orchard address;
- if yes, please share the payout amount and transaction ID.
Because Orchard transactions are shielded, I cannot confirm the payout from a public explorer, so I would appreciate your authoritative check from the Round 1 payout data.
Thank you very much.
Hi @alphiz22. We scanned both of your UFVKs and didn’t find any cTAZ rewards from mining or staking. Could you DM me screenshots of your staking transactions that show the transaction ID and the block height for each one? We’ll double check once we have that information.
Hi Jason,
Thank you for your response. I recovered my old VPS backup from Google Drive.
The address-specific export for my node address tmRB9AEVsxNAQsqtJPqJUje9KCaAijpS77z shows 30 Orchard staking transactions between block heights 110254 and 120756, totaling 410.00330 cTAZ including fees. The backup also records 63 accepted blocks at or below height 131000.
I have attached evidence showing every transaction ID and block height. Could you please manually cross-check these transactions against both UFVKs I submitted?
Thank you.
(Attachment Crosslink_Round1_Staking_Evidence.xlsx is missing)
Thanks. Give us a couple of days to look into this and we’ll follow up with you.
Hi all,
While setting up my nodes I noticed two things I’d like to flag for clarification — they may affect more testers than just me.
-
Default miner address. My config doesn’t set a
miner_address(onlyinternal_miner = true), yet all my coinbase outputs land ontmRB9AEVsxNAQsqtJPqJUje9KCaAijpS77z. This address also appears to be baked into the zebrad binary and seems to be used by other participants as well. If that’s the case, everyone who doesn’t set their ownminer_addresswould be mining to the same address — one that none of them actually controls. Is this known/expected behavior? -
Plaintext seeds in the public snapshots. The publicly distributed ctaz snapshots contain
secret.seedfiles in plaintext. Anyone who downloads such a snapshot receives the private seed of the wallet it was created with. This looks like a security concern, since it effectively hands out someone else’s keys.
For the record, I’m not claiming anything here — I only started testing on June 19. I just want to make sure these points get checked in case they aren’t already on your radar. Thanks!
@philthefirst, thanks for flagging this.
I downloaded the current published snapshot over the public link and listed every file in it. There’s no secret.seed, wallet, or key material in the archive. The secret.seed you’re seeing is written by zebrad into the cache when the node starts, so it appears locally after you restore and run the node, but it was never in the download.
The report did still catch a real tooling issue: the old restore helper preserved that file if it was present locally, which is the wrong default for shared recovery tooling, so I’ve changed restore to refuse key material outright.
If you ever see a plaintext secret.seed inside a specific downloaded archive rather than your running cache, send me the exact filename and I’ll verify that artifact directly.
Appreciated, this is the kind of flag worth raising.
Follow-up on the snapshot side: I also checked the public metadata/API surface. No seed, wallet, or key material exposed there either. I did find some internal path-style metadata in the public JSON, not keys, that shouldn’t have been public, and removed it.
So the distinction holds: a secret.seed showing up after you restore and start the node is local runtime state, not something shipped in the archive.
I will answer your first point since the snapshots aren’t distributed by shielded labs. The way the software is supposed to work is that when you don’t specify a miner address in the config it will mine to the wallet derived from the secret.seed file. Your wallet. In the early part of the chain most mining was done by our SL nodes, they were mining into the faucet wallet. This wallet is in everybody’s node / desktop wallet and allows people to request funds into their main user wallet. This is obviously totally insecure, but it has been fine for testing.
When you say “all my coinbase outputs”, what are you looking at exactly? Are you sure these are blocks recently mined by your node?
@alphiz22 Could you let us know which transactions were made using the desktop wallet and which were made using the mobile wallet? Also, if you happen to know which version or build of the software you were using at the time for each transaction, that would help us narrow things down. Thanks.
Hi Jason,
Thank you for following up.
You asked which transactions were made using the desktop wallet and which were made using the mobile wallet, and also which software version/build I was using at the time.
I prepared one complete evidence PDF and attached it here. It includes the UFVK split, software/build details, recovered VPS/Google Drive evidence, staking transaction evidence, accepted-block evidence, and mobile ZingoDelegator screenshots.
To clarify the wallet split:
Desktop UFVK = Crosslink GUI/node wallet running on my VPS.
Mobile UFVK = ZingoDelegator test app wallet on my phone.
I used both wallets during Round 1 and submitted both UFVKs before the deadline.
Desktop/VPS details:
zebrad 2.5.0
Crosslink monolith tag s1v7_1
commit 22a3df7f3d1650d83ca4b324fb6d6d55318a07ed
zebra-crosslink 1.0.0-beta.46
GUI package visualizer_zcash 0.1.0
Mobile details:
ZingoDelegator
version/build zingodelegator-0.0.1
network Testnet
server shown in app 70 dot 34 dot 201 dot 146 port 18234
My recovered evidence shows both node activity and staking activity.
Node/VPS activity evidence:
The recovered Google Drive/VPS backup shows 63 unique accepted blocks, including block heights and hashes. It also shows accepted blocks under or equal to height 131000 is 63.
Staking/cTAZ activity evidence:
The recovered staking evidence shows staking-related transactions with blockHeight, txid, txIndex, netChange_cTAZ, hasOrchard, and hasSapling fields. The full staking evidence screenshot also summarizes 30 Orchard staking transactions, first block 110254, last block 120756, and outgoing cTAZ 410.00330.
Important note:
I do not have a perfect transaction-by-transaction split showing exactly which individual staking transaction was created by the VPS GUI wallet and which one was created by the mobile ZingoDelegator wallet. That is why I submitted both UFVKs, and I am asking you to cross-check the recovered transaction/block evidence against both UFVKs together.
The attached PDF includes:
- Desktop UFVK and Mobile UFVK clearly labeled.
- Mainnet Orchard payout address.
- VPS/software version details.
- Mobile ZingoDelegator version details.
- Original Drive reward summary screenshot.
- Original Drive staking CSV screenshot.
- Full staking transaction evidence screenshot.
- Readable 63 accepted blocks pages.
- Mobile ZingoDelegator staking screenshots.
Could you please manually re-check both submitted UFVKs against this evidence and confirm whether the Round 1 scan detected the VPS/node activity and staking/cTAZ activity?
Thank you very much for taking the time to review it again.
(attachments)
Thanks Sam, that clears it up. To answer your question precisely: I wasn’t looking at blocks I had confirmed my own node mined — I queried getaddressbalance and getaddresstxids for tmRB9AEVsxNAQsqtJPqJUje9KCaAijpS77z and saw ~43k incoming entries, almost all dated before June 17. I assumed these were “my” coinbase outputs because my node uses that address, but from your explanation that’s the faucet wallet that SL’s own nodes were mining into during the early chain — so those aren’t mine at all.
My config has no miner_address set (only internal_miner), which I now understand should mine to my own seed-derived wallet rather than the faucet. I only started on June 19, so I have no claim on any of those pre-deadline outputs — I just wanted to understand where they came from. Appreciate the clarification.
Hi Jason,
I just wanted to check in — did you get a chance to review the complete evidence PDF I attached in my last message?
I’m happy to clarify anything or provide additional information if needed. I just want to make sure everything is in order on your end before you make a final decision on my Round 1 reward claim.
Thank you for your time.
Thanks for sending over the additional information. We reviewed everything you provided, but unfortunately we still weren’t able to verify the mining and staking activity using the UFVKs you submitted.
We were able to locate the transactions you referenced. However, the Orchard actions associated with those transactions couldn’t be decrypted using either of the UFVKs you submitted, so we weren’t able to tie the transactions back to your wallets or verify the staking activity on the blockchain. We also found that those transactions don’t appear to contain staking actions on-chain.
We also reviewed the mining information you provided. The block hashes don’t match the blocks on our chain, and the address associated with the mining activity appears to be the faucet address rather than one of your wallets.
Regarding the staking transactions, we’re currently looking into whether this could be related to the version of the ZingoDelegator app you were using. We’ve reached out to the Zingo team to see whether using an older version that was no longer supported could explain this issue.
One thing they were able to confirm is that you’ve successfully and visibly staked since block 131,000 (the Round 1 cutoff). Those staking transactions should be eligible for Round 2 payouts.
Quick question on Round 2 eligibility and the current chain state.
My node is fully synced (PoW height ~196617) and I’ve been mining to my own wallet for fun the last couple of minutes. I notice I can keep pushing the PoW height up by mining, but PoW-finalized stays frozen at 19138 — so I’m clearly just extending an unfinalized branch, and with the known fork situation my tip likely doesn’t match your canonical chain.
So my question: if I stake now (post-block-131k) on this current chain, would that count toward Round 2 — or will Round 2 use a new canonical chain / reset, meaning I should wait to stake until that’s announced? I’d rather stake on the chain you’ll actually evaluate than on a branch that won’t count.
