We are Rock’n’Block – a web3-native dev shop helping founders build, launch, and scale blockchain projects faster. From MVPs to full-scale platforms, we deliver competitive #Web3 products that stand out. 🚀 site: rocknblock.io portfolio: rocknblock.io/portfolio

New article is here: 10 RWA projects, from tokenized gold to collectible cards A fund share, allocated gold, an interest in a property-owning company and a vaulted trading card can all fall under the RWA label. That label alone says little about the holder’s actual rights or exposure. Our latest review looks at Ondo Finance, Securitize, Circle, Centrifuge, Figure, PAX Gold, xStocks, RealT, Toucan and Courtyard. It explains what stands behind each name and how their models differ. This is a map of the sector, not a ranking. Read the full review: rocknblock.io/blog/top-10-rw…

A private stablecoin transfer can hide its amount and counterparties from public observers. That still leaves several questions about who controls the money. 1. Who can view the transaction? Can only the sender and recipient access the details, or can they grant access to an auditor, payment provider or regulator? The system needs a clear disclosure and key-management model. 2. What can the issuer do? Depending on the token design, the issuer may retain powers to mint, burn, block transfers or freeze particular balances. Privacy does not make those controls disappear, so their scope and approval process must remain auditable. 3. Where are compliance checks performed? The product may verify eligibility, sanctions screening or transaction limits without publishing the underlying data. When the stablecoin is redeemed for bank money, the regulated off-ramp may still require the customer and transaction information prescribed by its rules. 4. How are errors and disputes handled? Teams need an answer for compromised keys, lost disclosure access, incorrect transfers and conflicting records. “The transaction is private” is not an incident-response procedure. 5. Who can change the system? Upgrades to verification rules, issuer permissions or disclosure policies can alter what privacy and control mean after launch. Those changes need governance, access controls and a visible audit trail. Private payments reduce unnecessary exposure. They do not remove the issuer, the off-ramp or the people responsible for operating the product.

Selective disclosure means showing a verifier only the information required for a specific decision. Consider a company that needs to prove a supplier payment was valid without making the supplier, invoice price and treasury balance public. The private side of the system may hold the invoice, identities, amount and authorization records. From that data, it can generate a cryptographic proof for a narrower statement: – The invoice was approved – The recipient passed the required checks – The payment stayed within the authorized limit – The hidden amount matched the approved obligation – The resulting balance update followed the agreed rules The verifier checks the proof and the selected public inputs. They do not need to receive the complete invoice or inspect every piece of data used to produce it. This protects the underlying commercial information, but it does not establish that the original records were truthful. If the invoice, identity credential or compliance result entered the system incorrectly, the proof can still confirm that the computation followed those incorrect inputs. The product therefore needs trusted data sources, clear issuers and a way to bind each proof to the correct transaction. Selective disclosure reduces how much information must be shared. It does not remove the need to verify where that information came from.

A supplier payment on a transparent blockchain can reveal much more than the amount transferred. Imagine a company paying the same address every Friday. The timing, frequency and size of those transfers begin to show a commercial pattern. Once either address is linked to a real business, observers may infer who the supplier is, how much work they receive and when the buyer moves money. The company may want to keep several things private: – The connection between wallets and legal entities – Invoice details and negotiated prices – Treasury balances – Payment schedules – The wider network of suppliers and partners At the same time, the business may still need to prove that a payment occurred, followed an approved invoice, went to an eligible counterparty and stayed within an authorized limit. That is the useful distinction: the settlement should be verifiable by the parties who need it, while the commercial relationship should not become public market intelligence. We’re preparing an article on how private but verifiable blockchain payments can make that separation possible.

New article is here: how ERC-8004 creates a trust layer for AI agents. An endpoint tells an application where to call an agent, but it says little about who controls that identity, whose feedback is credible or whether anyone checked the result. ERC-8004 proposes three on-chain registries for agent identity, reputation and validation records. These shared signals do not make an agent trustworthy by default. Each product still has to decide which reviewers and validators it accepts, what their checks actually prove and how much risk is appropriate for the task. ERC-8004 remains a Draft, so its interfaces may still change. Our new review explains the current architecture and the product decisions that remain outside the standard. Read: rocknblock.io/blog/erc-8004-…