We’re a web3 native development studio Here we share the latest news, insights, and tech that inspire us.
Worldwide
Joined March 2025
- Tweets568
- Following165
- Followers398
- Likes1K
Pinned Tweet
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
ALT rocknblock, rock'n'block, rocknblock.io
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-…
To receive an RGB asset, the recipient creates an invoice tied to a Bitcoin UTXO.
The sender constructs the new state transition and passes the recipient a consignment containing the relevant asset history. The recipient validates that data locally and checks its anchors against Bitcoin before accepting the transfer.
An RGB-capable wallet needs to manage Bitcoin UTXOs, create and read RGB invoices, exchange and store consignments, validate asset history and track every transfer state.
It also needs a reliable backup process. A block explorer cannot reconstruct data that was never published on the blockchain.
RGB can support a direct exchange between BTC and an RGB asset in one Bitcoin transaction, but the protocol does not create a market by itself.
The product still needs pricing, liquidity, routing, compliance checks and failure recovery.
For USDT, the infrastructure challenge is not limited to issuance. Wallets and services also need to handle the client-side data that makes each balance valid.
Tether has announced plans to launch USDT on RGB, a protocol that uses Bitcoin as its commitment layer while asset data is held and validated by the parties involved.
That is a different operating model from USDT on Ethereum or Tron. Here is what changes at the infrastructure level ↓
A borrower misses a payment in a tokenized credit product. What changes?
The answer comes from the loan agreement and the token terms, not from the smart contract alone.
The product first needs to determine whether the payment is late, within a cure period or already qualifies as a default.
Tokenholders need to know that the payment was missed, what action is being taken and how the expected repayment schedule has changed.
That does not mean publishing every piece of borrower information on-chain. Sensitive data can remain off-chain while the permitted status updates and calculations remain auditable.
A blockchain explorer says “confirmed,” but the user still sees a pending deposit. Both can be true.
Confirmation means the network has accepted the transaction at a chosen confirmation level. It does not mean the product has applied the result to the user’s account.
The missing step is application state ↓
We usually model the operation as a state machine:
Submitted → observed → confirmed → finalized → applied
The event handler should be idempotent, so the same event can be processed again without crediting the user twice.
Replay and reconciliation jobs are also necessary. They let the system recover missed events without someone editing balances manually.
Monitoring should cover the gap between the chain and the application, not only failed transactions.
The team needs to see when a transaction is final on-chain but still unapplied in the product, assign the incident to someone and recover without creating a second credit.
“Confirmed” is a blockchain status. “Completed” is a product status.
Private credit is lending arranged outside public bond markets, usually through negotiated agreements between a borrower and a fund or specialist lender.
Turning that loan into an RWA product does not begin with minting a token. It begins with defining what investors are buying and who keeps the product running after the loan is issued.
A typical structure involves:
1. A borrower who receives capital and owes repayment under a legal agreement.
2. An originator or manager who evaluates the borrower, structures the loan and monitors its performance.
3. A legal vehicle or fund that holds the loan or the related receivables.
4. A servicer who tracks repayments, late payments and changes to the loan terms.
5. Investors who receive tokens representing their position in the product.
Depending on the structure, the token may represent a fund share, a claim on a pool of loans or a right to distributions. It does not automatically give its holder direct ownership of the borrower’s collateral.
The legal documents determine those rights. The blockchain records and helps operate them.
The hard part is keeping the loan records, incoming payments, valuation, token supply and investor rights aligned throughout the product’s lifecycle.
We’ll unpack the full structure in an upcoming article.
