Ethan

I noticed something about institutional finance that doesn't get discussed enough: putting money onchain is one thing. Putting your entire financial playbook on display is another. Think about it from an institution's perspective. Trading positions, transaction records, business relationships, and financial strategies can all reveal valuable information to competitors. Public blockchains offer transparency, but institutions may not want every detail of their financial activity exposed. At the same time, keeping everything private creates another problem. If nobody can verify the information behind a financial claim, establishing trust becomes difficult. This is the problem I find interesting about @primus_labs. Primus is building confidentiality and verification infrastructure above existing onchain financial rails. The idea is to help protect sensitive information while making it possible to verify what needs to be trusted. Here's how I understand the approach: → Verification: Prove what needs to be trusted, including financial information held offchain. → Confidentiality: Protect sensitive information instead of exposing every detail publicly. → Existing infrastructure: Bring confidentiality and verification capabilities above existing onchain financial rails. What matters here is how these pieces work together. Institutions need to protect their positions and strategies, but they also need credible ways to establish trust when verification is required. Neither privacy nor verification can address the entire challenge alone. That's why I think the next phase of institutional adoption isn't simply about moving more money onto blockchains. It's about making onchain finance practical without forcing institutions to choose between confidentiality and verifiability. Can onchain finance deliver both? Explore Primus XP and complete the available tasks: s.kaito.ai/CYSEV1s

One thing that gets overlooked in the quantum security debate is who actually gets to decide when a blockchain upgrades its cryptography. @Starknet exploring its own L1 makes this question worth paying attention to. There's an important distinction here. Starknet currently operates as an Ethereum L2, which means some parts of its security architecture depend on Ethereum. Its STARK proofs use hash-based cryptography, and its programmable accounts make it possible to introduce new signature methods without requiring a network-wide upgrade. But that doesn't remove every dependency. Starknet still relies on Ethereum for parts of its bridge and data availability setup. Some of those components use cryptographic mechanisms that will need to be addressed as Ethereum progresses with its own post-quantum migration. That creates a coordination problem. Even if Starknet is ready to change a component on its side, certain changes depend on what happens at the Ethereum level. An independent L1 could give Starknet more control over the timing of its core security upgrades. That doesn't mean the transition is decided, or that every technical challenge disappears. It means the team is exploring a different way to manage those dependencies. The community's recent vote supported further research into this direction, not an approved L1 transition. To me, that's the important distinction: preparing for future cryptographic threats isn't only about the mathematics. It's also about having control over how the necessary changes get implemented. The technical details and migration roadmap are worth exploring here: quantum.starkware.co/

A subtle but important point about blockchain security: the ability to upgrade your security can matter just as much as the security you have today. That’s one part of @Starknet I think deserves more attention. The concept is simple Whenever you make a blockchain transaction, your account needs to prove that you’re authorized to make it. That usually involves a digital signature. The challenge is that cryptography evolves. A method considered reliable today may need to be replaced as new threats emerge, including potential advances in quantum computing. On some systems, changing how signatures are verified can require changes at the protocol level. Starknet takes a different architectural approach through programmable accounts. Think of an account like a lock with its own verification rules. If a better locking mechanism becomes necessary, a new account implementation can adopt a different way of checking authorization without requiring the entire network to change its rules at once. That flexibility matters. Starknet’s native account abstraction allows new account implementations to use post-quantum signature verification. But there’s an important distinction: existing accounts don’t automatically become quantum-resistant, and wallet support, key management, audits and adoption still matter. So this isn’t a claim that every Starknet account is already protected against quantum threats. It’s about having a practical route to adapt as cryptographic requirements change. To me, that’s the real value of cryptographic agility: not assuming today’s methods will be enough forever, but building a system that can evolve when they need to change. Starknet’s Quantum Hub explains the architecture in more detail: quantum.starkware.co/archite…