The Bitmap Standards I've just published bitmap GitHub, with the refined Standards for Districts and Parcels. It serves to clarify any grey areas. github.com/Blockamoto/bitmap If there are any questions that cannot be answered by the wording of these two standards, then there is still work to do. You can read my rationale in the audit branch, including pages for standard and non-standard rules in historic indexer audits.

Look forward to tomorrows update, it's getting good! 🫡 It's the Transaction locator index, with some major improvements on design, functionality, and exploration, including bitfeed.live style visualiser for blocks and an improved mempool.space visualiser for transaction flows. Turn your X notifications on from me 🔔

Ten more votes and we'll be in the top 100! Vote @blockamoto and @BitmapSunset and any other bitmapper you think deserves it! 🫶🏼 #bethebitmap

Introducing Gateway... I've been building a new kind of Bitcoin client. One that ANYBODY can run regardless of storage. Fetch only what you need, when you need it. On-demand, directly from Bitcoin peers. This is at the heart of Gateway. Sparse-by-default deep on-demand p2p-Bitcoin indexer. Now, I recommend you feed this post your favourite AI and have it talk to you directly about it, because I'm about to get into the weeds. And I'm very excited, so it's probably better you ask your AI how this applies to you, rather than leaving a comment that it's too complicated or that you don't understand. With that being said, if you're happy to go hardcore old-school style, and actually... read the thing, here it is! BITCOIN PEERS Traditionally, Bitcoin clients sync nodes by requesting blocks from other peers one-by-one, from zero. This is somewhat impractical for everyday users. Gateway does things differently. You can certainly sync the entire blockchain using Gateway, and become a full Bitcoin Node, and a useful Bitcoin Peer. You can even bring your existing Core node and plug it in if you already have one. But that's not the interesting part. The interesting part is that you don't need that. Seek data directly from Bitcoin Peers, on-demand. ON DEMAND Unlike Core, Gateway does not require you to sync the entire blockchain. You can sync any range, or even just type in a block number in the top bar to fetch the block from a Bitcoin peer directly. This approach is extremely useful for Blocks, but it has some limitations. Transactions (and thus, inscriptions) cannot be resolved directly, without knowing the block number. The latter part of that sentence is the important part. Gateway adds a schema that allows you to type "{tx}.{block}.bitcoin" and resolve a transaction directly from a Bitcoin peer. You can replace {tx} with either tx-hash, or tx-index (which is a new schema for Gateway), and {block} with either block-hash or block-height. For example: 0.0.bitcoin This becomes relevant for inscriptions. An inscription ID is simply: {tx-id}i{inscription-index} So you can resolve inscriptions by including block-number in the scheme: {inscription-ID}.{block}.bitcoin If you know the transaction index, you can even use that instead of transaction ID in inscription ID. That means, so long as you know the block number, any inscription can be resolved on Gateway, on-demand, by asking a Bitcoin peer directly. ORD When it comes to Ord, this is an extra layer on top of Bitcoin. It is an indexing system that takes Bitcoins already heavy data store, and adds its own index that can take roughly a week to sync. For the everyday user, this is not practical. Whilst I've demonstrated how we can fetch inscriptions directly from Bitcoin Peers without Ord, you need to know block number, and the standard in Ord is to use inscription ID, sat number, or inscription number as the key reference. I've added block in the Gateway schema as a useful primitive that enables purely on-demand inscriptions from Bitcoin peers, but that isn't the current standard. INDEXES This is where you can build your own data-store directly from Bitcoin data originated through Bitcoin peers, and either become a useful participant of the network, or take what you need privately. The baseline index is Bitcoin Blocks. However, you do not need that to resolve the other indexes. Each index has an "ephemeral" option, which means to seek the blocks you require from peers, strip the data you need, and discard the blocks. This is useful if you're running this on your everyday computer, and can't be spending so many GigaBytes on Bitcoin. For example, you can index Bitmap without storing a single block. The indexes are generally layered, so you can choose what you would like to index and when. If you index Bitcoin Blocks, you will be asked if you also want to index the other downstream indexes in parrallel, since it would be quicker to do that than re-run the index. If you already have a Bitcoin Node, you can build other indexes on top of that. But you don't have to have the Bitcoin blocks to sync inscriptions, Bitmap, or any other index we implement. Now, this is still some heavy lifting, but once we start activating the Gateway peer network, we can supercharge these capabilities. GATEWAY PEERS Gateway users can connect to each other in a peer-to-peer network, just as in Bitcoin. That means that, whatever data you need, you can ask Gateway peers directly and skip indexing directly from Bitcoin data, with Bitcoin as the hashed proof verification layer. So, anything your Gateway node doesn't know, or is impractical for you to find through Bitcoin peers, can be served by Gateway peers. This vital peer layer can become more useful as we start adding other cases for the Gateway peer network, for example, you could opt-in to become a persistent relay for a Bitmap or Ord gaming webRTC layer. We can even serve this p2p mesh layer to websites and ordinals over the web, so in the future, you will be able to connect to gateway from a website, or from an Ordinals inscription. For now though, it requires the Gateway client. But the dream is that you can become a useful OR private participant in Gateway from different angles. LONG STORY SHORT A sparse-by-default on-demand bitcoin node, with full-range indexing and p2p sharing with gateway nodes. EARLY RELEASE TESTERS I am seeking early testers who are happy to put the client through the ringer, vet the data, or just try and break the thing so we can make sure we ship a proper robust client. You can comment on this post if you're interested, and I'll share details when it's ready for testing. At this stage, I just wanted to let you know that I have a client, it's working, it's almost ready for testers. WHAT NOW? This is just one of the things I've been working on and excited about recently, but it's the one I think is the most important in terms of vital infrastructure that can benefit the entire stack from Bitcoin peers to Bitmappeers. Stay glued to my timeline for more! 👀 Comment if you want to get involved. 💬

It's time to get excited about ORD and BITMAP again. Why? Because /r/block just got merged!! What does this mean? We now have full block data through recursion!! What problem does this solve? TL;DR: we can now accurately draw Bitcoin Maps! Up until this merge, it has been impossible to resolve transaction data within an inscription without knowing the txid. That means, the full promise of Bitmap has been impossible on-chain via ord, because we cannot represent accurate transaction data. THE SOLUTION /r/block/<query> : full block hex for <hash or height> One week ago, I submitted a PR issue to Ord that would allow you to fetch full block hex with one call. It was after working with Astra to close the gap. Originally I was going to build fetching txid from blocks, but it became clear that this would lead to thousands of recursive calls per block. Astra suggested using /r/block instead to get the full block hex. With one call, you get all transaction data from the block. I wholeheartedly agreed. It just made sense. I put Astra to work and it was done within 20 minutes. I tested it on my node and it worked a charm, then I submitted my PR as an issue to ord. Last night, Casey merged /r/block/<query>. So now we have full block and transaction data! This is a game-changer for bitmap. So this morning, I'm working on something to show what is now possible. See image for a clue. But more importantly, the endpoint is available now for you all! This is truly an exciting moment, and will open a dam of development on Ord and Bitmap. Use it wisely, and build procedurally. Please show Casey some Bitmap love on this historic merge. Happy building!

🏘️ HOOD 0 REPORT 🏘️ **DISTRICTS 0-2015** What's good in Hood 0? This is my first Hood report. I will report Hood by Hood primarily, and reporting any updates as I learn about them. Feel free to write your own Hood reports! Hood 0 is the first Hood on bitmap, representing the first 2016 blocks of Bitcoin, and the earliest Bitmap inscriptions. There have been 6 Districts reinscribed and 3 Parcels inscribed, totalling to 9 events. The Hood Seat is 0.bitmap, with only it's self-nomination vote. Here are the inscriptions that have been made in Hood 0, starting with the latest: PFP of @blockamoto (art by @BankofNFTs) 0.bitmap | 17/04/2026 I inscribed the Blockamoto PFP has when I first launched bitmap.land, the first inscription on 0 since it became the first ever bitmap inscription. It included my self-nomination for Hood Seat, so I could test and demonstrate how it works. Currently still the only Signal vote in Hood 0, so you could quite easily overthrow me here with just 1 additional vote. Imagine by John Lennon @21_bitmap 1971.bitmap | 21/02/2026 The iconic lyrics of John Lennon, one of a few different poetry inscriptions made across the bitmap by @21_bitmap. Bitmap Registry Library by @Bitmaptoshi 1981.bitmap | 15/12/2025 It combines an off-chain/indexer-style registry and monitoring system with an on-chain HTML interface (the provided inscription) that acts as a queryable oracle/GUI for Bitmap data within the Ordinals/Bitmap ecosystem. 0.4.bitmap parcel by @Switch_900 4.bitmap | 30/12/2024 Atlas Code by @boppleton 609.bitmap | 20/08/2024 An on-chain IDE for writing, running, and testing code. Extremely useful, and has great code formatting. 0.0.bitmap parcel by @blockamoto 16/5/2024 0.404.bitmap parcel by @fishbrainctrl 16/05/2024 Bitworld 2014 from @luminexio 2014.bitmap | 7/11/2023 Back in 2023, Luminex offered Minecraft style worlds generated from your Bitmap as reinscriptions, using the brc69 standard. Way ahead of the game. I don't know who inscribed this. Bitworld 1149 from @luminexio 1149.bitmap | 6/09/2023 This was the first reinscription of a Bitmap within Hood 0! Once again, I don't know who inscribed this. JOIN HOOD 0! Let's activate these smaller communities, work together, and build out Bitmap from the ground up.

🏷️ Bitmap Metadata 🏷️ Act upon your territory. Control your land, impact your neighborhood at bitmap.land. 🖼️ Content 📍 Bulletin 🗂️ Directory 🏷️ Name 🎨 Color 🚩 Flag 🗳️ Signal 🪑 Seat Read the full Metadata standard by clicking ❓ at bitmap.land. 🖼️ Content 🖼️ Change what appears on your square of the map. Reinscribe your District or Parcel with content or delegate content. 📍 Bulletin 📍 This is a text notice accompanying your reinscription. Think of it like a blog post, a tweet, or the otherside of a postcard. These bulletins are resolved when a Hood is sync'd, so you can treat it like a community notice board. 🗂️ Directory 🗂️ You can append a link-tree to your Bitmap District or Parcel by reinscribing it with Directory in the Metadata. You can view all directories within a Hood in the Hood Discovery 🏘️ panel. 🏷️ Name 🏷️ Name your District or Parcel. 🎨 Color 🎨 Change the color of your District or Parcel. 🚩 Flag 🚩 Set any inscription as a Flag for your District or Parcel. 🗳️ Signal 🗳️ Vote on a District within your Hood to become it's Hood Seat. Votes are counted every Difficulty adjustment. Seats must nominate themselves for votes to be valid. Districts may defer their Seat vote to their Parcels, so Parcels may vote on what that Districts vote is. 🪑 Seat 🪑 The District that is the Seat of the Hood may make decisions and act directly upon the Hood. At this stage, a Seat may choose the Name, Color, and Flag of a Hood. They may also defer this choice to a District vote (and Districts may defer to Parcels). Latest content, bulletins, and directories from Hood Seats are pinned to the top of the Hood Discovery page. This is intended to encourage community decision making for the bitmap.land platform, and any others that adopt these standards. And to give citizens the opportunity to represent their Hood, either directly as Seat, or through their on-chain voice in the standards set out above. ::FINAL WORD:: Metadata is where we can set our parameters for our Bitmap, and such there is a lot of work to be done, but I think this is a good start. Remember to check the standard by clicking ❓ at bitmap.land and I hope you enjoy! ✊🟧🗺️

What is bitmap.land SYNERGY? ⚡ Collect ⚡ to build out your map. SYNERGY means "sync energy". It's a point system for synchronizing Hoods. Click block popups, earn ⚡, sync Hoods. It cost 1 ⚡ per hood. Even when zoomed out, bitmap reinscriptions of sync'd Hoods are visible on the map. More on that soon... To sync the entire map without your own node is a lot to ask of @rodarmor's ordinals.com servers. If you are running a local node, bitmap.land will allow you unlimited sync's. For those who don't, this gamified system allows you to sync what you want to without overloading ordinals.com, whilst doubling as a mini-game loop giving you reason to return to bitmap.land: to build out the bitmap. SYNERGY was released in yesterday's inscription, which can be found at bitmap.land. HOW TO EARN SYNERGY ⚡ 1. Wait for a block to be mined. 2. Click the NEW DISTRICT popup 3. This earns you SYNERGY ⚡ HOW TO SPEND SYNERGY ⚡ There are three ways to use ⚡: 1. Turn on Autosync 2. Manually sync Hoods 3. Sync your subscriptions Note: in bitmap, a Hood consists of 2016 adjacent districts, aligned to 2016 blocks within a difficulty period of Bitcoin. HOW TO AUTOSYNC This is the easiest and for me, most fun way to use SYNERGY ⚡. 1. Click the ⚡ in the top-right 2. Switch AUTO ON 3. Hoods will sync from your ⚡ HOW TO SYNC MANUALLY This is the default, as auto-sync is turned OFF by default. 1. Go to Hood Discovery: 🏘️ 2. Enter Hood number 3. Click "sync" to sync the Hood Note: you can switch "Districts + Parcels" BEFORE clicking sync to include parcel inscriptions and reinscriptions. In this version, this consumes the same ⚡. SYNC SUBSCRIPTIONS District/Parcel subscriptions are free*. Hood subscriptions cost ⚡. 1. Go to 🔔 SUBSCRIPTIONS 2. Check sync cost 3. Click "sync" to start *You can sync up to 2015 Districts for free before it's considered a Hood sync. Each 2016 District's costs 1 ⚡ to sync. Note: you can subscribe from any District, Parcel, or Hood page by clicking the 🔔 icon. Another note: I'm noticing the top bar 🔔 isn't appearing on my phone. It's likely a common font issue, so just tap the blank button. That's the low-down on SYNERGY ⚡! Let's be kind to Casey's servers, and have fun whilst doing it. The image below is how far sync'd I am on my phone so far. I'd love to see screenshots of your zoomed-out sync's! But most of all, have fun. I warn you... it can be addictive. 🫢

The inscription got dropped from the mempool, but I have an update coming with new features which I will make sure it gets mined, so set your notifications! 🔔 #satmap #bitmapdirectory #bitmapbulletin