Bron is a self-custody wallet that lists Canton Coin among its networks. The Lens // InFocus No. 10 reads only Bron's own pages. What do they confirm? Custody first. The key is split into three shards, on your device, on a Bron server and with Qrypt, and any two restore it. Shared control by design. On Canton, Bron's help pages describe a dual-signature receive. That matches the two-step transfer in Canton's token standard docs, where the sender instructs and the receiver accepts. Bron says a pending offer expires after about 10 days. Each Canton Coin transfer becomes its own holding with a fixed fee over time, and one transfer can use at most 100 holdings. Bron and Canton's docs agree, in plain words. The code is public. Trail of Bits' January review lists 24 of 25 issues resolved. The harder read is that the readme says the current Lindell17 adaptation postdates that review. Where the pages stop, the ecosystem directory tags Bron as a featured app and validator. Bron's own pages don't say either, so both stay announced. When the Lindell17 adaptation gets its own outside review, will Bron publish that report too? Sources: Bron: bron.org/ Impossible Wallet: bron.org/impossible Supported networks: support.bron.org/en/articles… Receiving: support.bron.org/en/articles… Canton Coin tokenomics: docs.canton.network/overview… Trail of Bits review: github.com/trailofbits/publi… bron-crypto: github.com/bronlabs/bron-cry… Canton ecosystem: cantonecosystem.com/ I hold $CC and $CNTN. Disclosure at cantoncatalyst.xyz/disclosur…

Does it matter who runs the node when an exchange operator joins @CantonNetwork? Nasdaq's answer is that it'll run its own. On 26 Oct, the Canton Foundation's Tokenomics working group awarded Nasdaq, Inc. one MainNet validator node allocation. Nasdaq applied on 21 Oct. A validator is an operator that checks the transactions it is part of. The allocation lets Nasdaq run one on MainNet, the live network. Its application says the node will host Nasdaq's own applications. The same application says Nasdaq will operate it directly rather than through an existing operator. That choice matters to me more than the award. Nasdaq could have plugged into someone else's node and chose not to. Running your own node means your team holds the keys and keeps it up. $CC holders can't count anything from the award yet. A node adds activity once an app on it starts sending transactions, and the notice names no app. A post-trade or collateral desk dealing with Nasdaq on Canton would diligence Nasdaq itself, with no operator in between. What's missing is a start date. The notice says allocations are issued in line with current network capacity and ongoing health assessments. Filed, then approved. Live is the next step. Which application will Nasdaq put on its validator first? Sources: Nasdaq allocation notice: lists.sync.global/g/superval… Nasdaq application: lists.sync.global/g/tokenomi… I hold $CC and $CNTN.

Who decides which Canton apps become Featured Apps, and what does the vote record on the ledger show? The Canton Coin white paper says every app starts unfeatured, with capped rewards. Super Validators, the operators that jointly run and govern the shared network, lift the cap with a two thirds vote. On round 119022 the public Scan API shows featuredAppRewardCap 1.5 against unfeaturedAppRewardCap 0.6. The grant is a voted ledger action. Scan returns 291 closed grant requests since 2024. 271 were accepted, 17 rejected, 3 expired. 166 were accepted in 2026, 102 of them requested by the Foundation's own Super Validator. 139 rights are live. By my count of the written reasons, 15 of the 17 rejections cite paperwork, a duplicate or a wrong party ID. The screening sits before the vote. The Foundation's request form sends each app to the Tokenomics Committee and asks for an SV sponsor, controls against non bona fide transactions, and 14 days live. CIP-0104 is Approved and still reads the right at each round open, so the vote stays the gate. New guidance sits in an open pull request, so it is announced, not live. When the next votes land on Scan, will any rejection give a reason about the app itself? Sources: Canton Coin white paper: digitalasset.com/hubfs/Canto… Scan API, round reward caps: api.cantonnodes.com/v0/dso Scan API, featured app rights: api.cantonnodes.com/v0/featu… Scan API, vote results: api.cantonnodes.com/v0/admin… Canton Foundation Featured App Request: canton.foundation/featured-a… CIP-0104: raw.githubusercontent.com/ca… CIP-0104 amendment, pull request 262: github.com/canton-foundation… I hold $CC and $CNTN. Disclosure at cantoncatalyst.xyz/disclosur…

Who sees all of your party's data on Canton? One line in the Canton privacy docs answers it, and I think it deserves more attention than it gets. "Your validator is the one entity that sees all your party's data." Quick gloss. On Canton, a party (a person, a firm, a desk) is hosted by a validator node. Because each validator stores only the data for the parties it hosts, there's no global copy of everyone's state sitting on every node. That puts a real decision in your hands. The docs suggest choosing a validator with the same care you'd give a custodian or a cloud provider. The same page covers auditability. Your Participant Query Store (PQS) gives you a SQL database of your own ledger history, limited to what your party can see. Scan, the public service for the Global Synchronizer, shows network-level data like rounds and aggregate stats, without private contract data. The principle they land on is that each party can audit everything it's entitled to see, and nothing more. Who hosts your party today, and did you pick them on purpose? docs.canton.network/appdev/d…

Can a payments app keep your balance private while your handle is public? @HandlPay is betting its 2.0 rebuild on Canton to do it, and the launch just slipped. In a 26 Oct update, HandlPay said 2.0 now targets a public launch in mid-December, with selected users getting access a few weeks earlier. It had aimed for the end of Q3. The bigger change is announced, not shipped. HandlPay's 2 Oct recap says every payment a user receives will land in a @CantonNetwork wallet. The sender's side runs on EVM, and a bridge moves the funds to Canton behind the scenes. HandlPay's docs say only you and the sender can see each Canton transaction. So a public handle need not mean a public balance. I think the date matters less than the routing. A missed quarter is a scheduling problem. Moving every receipt onto Canton is the real bet, and it isn't built yet. If you hold $CC, watch usage after launch, not the launch itself. For a payments compliance team, the question is where visibility sits. I'd expect monitoring to live on the bridge leg. The fair counter is that this is the second moved target. The same recap listed 2.0 under what to expect in October. Plumbing first, then the date. When selected users get 2.0, will their payments already land on Canton? I hold $CC, $CNTN and $HANDL. Sources: HandlPay 2.0 update handlpay.ghost.io/handlpay-2… · HandlPay recap handlpay.ghost.io/monthly-re… · HandlPay docs docs.handlpay.com/concepts/s…

Node operators earn Canton Coin but pay many of their costs in dollars. ShadowDesk v2 is a private desk built for selling that CC. A builder posting as Saberdev put it on the Canton forum on 26 Oct. The mechanism is a mandate that two people sign on the ledger. It sets which trading desks can quote, the most that can be sold per trade, the worst acceptable price and an expiry date. An agent sells only inside those limits. Desks quote privately, the best price wins by a fixed rule, and both sides settle in one transaction or not at all. The rest is announced by the team. They say version one let the agent skip the mandate, and that they found the bypass, fixed it and now test for it four ways. They also say two competitive trades settled on DevNet, Canton's developer test network. I'd give the bypass admission more weight than the trades. A tool like this only earns its place if the network, not the agent, holds the limit. If you hold $CC, this doesn't change how much operators sell. It changes how, with size and price caps written down before an order goes out. For a validator's treasury team, a co-signed mandate with a desk allowlist works like a written sales policy that the ledger enforces, which is easier to show an auditor than a script holding the keys. The limits are plain. It's DevNet, no real money moves and the CC to stablecoin leg isn't built yet. Policy first, then the sale. I hold $CC and $CNTN. If you run a node, who converts your CC today, and what limits do they work under?