Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Open Data / Spatial Metadata
Luke Rohenaz revisits MAP as a way to give on-chain records real-world context
Luke Rohenaz has recently revisited the Magic Attribute Protocol, or MAP, drawing attention to an older open protocol whose usefulness extends beyond the applications for which it was first developed.
MAP provides a simple way to attach structured key-value metadata to on-chain data.
A record can say what type of thing it represents, identify something it relates to, reference another transaction or URL, or associate the data with a location.
Geohashes make the spatial possibility particularly interesting.
A geohash represents an area of the physical world as a compact text identifier. When included as MAP metadata, an on-chain object can therefore carry a machine-readable relationship with a particular place.
Current 1Sat Ordinals documentation demonstrates exactly that pattern by attaching a geohash to an inscription through MAP metadata.
The wider idea is not limited to collectibles or digital media.
Agricultural observations could be associated with a field. Infrastructure records could relate to a particular site. Local announcements could identify the area they concern. Images, environmental measurements, events, physical assets, or public records could all carry standardized contextual information that independent applications can read.
MAP also allows other kinds of relationships. One record can identify another transaction, describe itself as a particular type, or state how it relates to some external resource.
That makes it less a dedicated mapping protocol than an open contextual layer.
There is an important boundary, however.
Putting a geohash into a transaction does not prove that someone or something was physically present at that location. It records the location being asserted or referenced. Stronger claims may still require signatures, trusted sensors, certificates, attestations, or other evidence.
The value of the open metadata layer is different: independent applications can understand the same contextual identifiers without first agreeing to use one company’s private database.
MAP has existed for years. Its renewed relevance may come from the kinds of systems now being built around it, where applications, physical-world data, and AI agents increasingly need machine-readable ways to understand not only what a record contains, but where it belongs and what it relates to.
Source: Magic Attribute Protocol / 1Sat Ordinals Metadata / 1Sat SDK
Developer Standards / Community Resources
The BRC toolkit is developing different paths from discovery to contribution
As the collection of Bitcoin Request for Comments grows, finding the right specification can become a problem of its own.
A recent look at the available BRC resources helps distinguish three different tools around the same body of standards: Beersy for discovery and explanation, BSV Hub for formal reference, and GitHub for proposing and discussing the specifications themselves.
Beersy approaches the library from the reader’s side.
Instead of requiring someone to already know the number of the standard they need, it allows BRCs to be searched by subject, author, title, or the problem a developer is trying to solve. Individual standards begin with a plain-English explanation of why they exist and what they enable.
It also provides AI-assisted questions grounded in the specification being viewed. The original specification remains available alongside the explanatory material, keeping the generated explanation separate from the authoritative text.
BSV Hub serves a different purpose. It provides a structured reference library for reading the BRC specifications and following the wider set of standards that make up the application architecture.
GitHub is where that architecture remains open to contribution.
A builder proposing a new BRC can fork the repository, prepare the specification, and submit it through a pull request. Discussion around existing proposals can take place through issues, while substantial changes are generally introduced through new specifications rather than silently changing standards on which implementations may already depend.
The distinction may seem administrative, but it becomes increasingly important as an open standards system grows.
Standards need to be written, but they also need to be discoverable, understandable, referenceable, and open to improvement.
Beersy, BSV Hub, and GitHub are beginning to represent those different stages of the same process: find the relevant idea, understand it, examine the specification, and participate in its development.
Source: Beersy / BSV Hub / BRC GitHub repository
Wallet Standards / Application Reliability
BRC-177 gives unbroadcast wallet transactions a recoverable deadline
BRC-177 addresses an unusual consequence of handing a signed transaction to someone else without broadcasting it yourself.
BRC-100 applications can create a transaction using the noSend option. The wallet constructs the transaction but does not broadcast it, allowing the application or another participant to deliver or submit it later.
The difficulty appears when that later broadcast never happens.
The wallet has already committed funds to the transaction. Because valid transaction bytes may now exist outside the wallet, simply cancelling a timer inside the application cannot safely make those funds available again.
The external party could still broadcast the original transaction later.
BRC-177 introduces a wallet-enforced expiry mechanism for this situation.
Rather than allowing an ordinary wallet input and potentially substantial change to remain reserved, the wallet first creates and broadcasts a dedicated funding output sized for the intended transaction. The protected noSend transaction spends that particular output.
A deadline can then be specified as a number of seconds, a Unix timestamp, or a block height.
If the wallet observes the protected transaction being broadcast before the deadline, it moves into ordinary transaction and proof tracking.
If no broadcast has been observed when the deadline arrives, the wallet can spend the dedicated funding output back to itself. Once that reclaim transaction is mined, the previously handed-off transaction can no longer spend the same output.
The mechanism also limits how much wallet value becomes tied up in the pending action. A small payment does not need to reserve a much larger input merely because the wallet originally expected to return change.
There is an important limitation.
BRC-177 does not create a consensus rule saying that the original transaction becomes invalid at a particular time. Around the deadline, the original transaction and the reclaim transaction can still race. The blockchain ultimately establishes which conflicting spend succeeded.
That distinction keeps the proposal grounded in the existing UTXO model rather than introducing a new transaction-expiry rule.
This is a relatively small wallet feature, but it addresses the kind of failure condition that becomes important as BRC-100 applications move beyond simple demonstrations.
Applications need transactions not only to work when everything goes correctly, but also to recover safely when recipients disappear, processes stop, network delivery fails, or a transaction is never submitted.
BRC-177 gives that unfinished state a defined way to end.
Source Links:
Magic Attribute Protocol overview
1Sat Ordinals metadata documentation
Update — September 5, 2026
Leave a comment