🔐 STRK20 Brings Selective Privacy to Starknet with Auditor Access
🔐 STRK20 Brings Selective Privacy to Starknet with Auditor Access
🔐 Privacy meets compliance
STRK20 introduces privacy features for ERC-20 tokens on Starknet while maintaining regulatory compliance through encrypted viewing keys.
Key Features:
- Private balances, transfers, and swaps for any ERC-20 on Starknet
- Fixed cost of 4 $STRK per transaction, regardless of size
- Single shared privacy pool that strengthens as more users join
- Encrypted viewing keys allow authorized auditors to access specific information on legitimate requests
How It Works: Users can shield ERC-20 tokens into private balances, conduct private transactions, then unshield with one click—all within the same wallet and liquidity pools.
The framework leverages Starknet's provable computation capabilities to verify private transactions without exposing details. As the privacy pool grows with more users and assets, individual transactions become harder to isolate.
Ecosystem Expansion: STRK20 is rolling out across Starknet with integrations for avnu and Ekubo, plus an open-source SDK. The Proof of Privacy incubator supports teams building private applications for payments, trading, identity, and DeFi.
Privacy by default, accountability when required.
Starknet v0.14.3 Goes Live with 1.5s Blocks and Dynamic Gas Fees
Starknet has deployed version 0.14.3 to mainnet, introducing several technical improvements to the network. **Key updates include:** - **Dynamic L2 gas base fee** - An automatic algorithm (SNIP-35) adjusts minimum gas fees based on STRK token price, aiming to stabilize costs in real-world value rather than nominal token terms - **1.5-second block times** - Reduced from previous intervals to lower transaction latency - **Enhanced prover/verifier capabilities** - New support for privacy-related transaction flows - **BLAKE-based SNOS hash** - Part of the network's long-term security infrastructure Developers working on fee estimation, sponsored transactions, paymasters, wallets, or account abstraction should review their implementations. The dynamic fee adjustment may require larger buffers during price volatility periods. Full technical documentation and compatibility details are available through the governance proposal and community forums.
🚨 RPC 0.8 Support Ends: Migration Required
**Breaking Change Alert** Starting with v0.14.3, RPC 0.8 is officially deprecated. Full nodes and SDKs will no longer release versions supporting it. **Action Required:** - Migrate to RPC 0.9 or RPC 0.10.1/0.10.2 immediately - Review your infrastructure if you rely on candidate transaction timing **Key Change:** Candidate transaction latency will now match preconfirmed transactions - no performance advantage. Apps depending on faster candidate transaction speeds need to reassess UX and infrastructure assumptions. This follows the earlier deprecation of RPC versions below 0.7, which was announced with Starknet v0.13.4. Developers should ensure they're using starknet-js v6.9.0 or later for compatibility.
🚨 Starknet Mainnet v0.14.3 Launch Checklist
Starknet v0.14.3 launches on Mainnet July 8th with critical updates requiring immediate action from builders. **Key upgrades include:** - Improved fee predictability - Lower latency - New privacy flow proving support - Breaking changes requiring preparation **Required actions before launch:** - **RPC users**: Migrate from 0.8 now - **Node operators**: Upgrade to v0.14.3 before launch - **Large transaction senders**: Review [SNIP-40 limits](https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-40.md) for transactions with thousands of reads/writes - **SNIP-36 users**: Upgrade provers alongside version update - **Hash-dependent projects**: Check Pedersen → BLAKE change impacts - **Timing-sensitive apps**: Review candidate transaction timing expectations This is a mandatory upgrade with breaking changes - projects must prepare to avoid disruption.
Starknet Core Contract Switches to Quantum-Resistant BLAKE Hash
**Starknet is upgrading its security infrastructure** by transitioning from Pedersen to the quantum-secure BLAKE hash function for program hash and config hash in its core contract. **Key changes:** - Program hash and config hash now use BLAKE instead of Pedersen - Enhanced quantum resistance for core contract security - SNOS (Starknet Operating System) verification affected **Action required:** Developers and infrastructure operators should verify compatibility if their systems depend on: - Program hash operations - Config hash operations - SNOS verification processes - Indexing services - Monitoring tools - Custom core-contract tooling This upgrade represents a proactive step toward quantum-safe blockchain infrastructure as the industry prepares for potential future quantum computing threats.
Starknet Adds Keccak Support for EVM-Compatible Private Transactions
Starknet's SNIP-36 verifier now supports Keccak built-in invocations in virtual OS blocks, enabling **virtual private transactions signed with EVM signatures**. **Key changes:** - New verifier functionality allows EVM-style signatures for private transactions - Requires prover service upgrade to v0.14.3 - **Breaking change**: Proofs from v0.14.2 are incompatible with the new verifier **Action required:** If you're using SNIP-36 proving, upgrade your prover services immediately alongside the v0.14.3 release to maintain compatibility.