N-Button Turns a Few Lines of HTML Into a BSV Payment Button

Payments Infrastructure

N-Button takes a deliberately simple approach to adding BSV payments to a website.

Created by Joel Dalais, the component can be embedded into an ordinary webpage with a small amount of HTML. The publisher specifies the amount and payment settings, while the button hands the actual payment interaction to Link, Dalais’s wallet/payment environment.

The idea is less about creating another checkout platform than reducing the amount of payment-specific application work required for a simple transaction. N-Button supports configurable amounts, payment splits, visual themes, receipts and post-payment redirects, allowing a developer or website operator to add a payment action without building an entire wallet integration around it.

There is an important dependency: the payer needs Link. N-Button is therefore not a universal browser payment standard, and its usefulness will depend partly on adoption of the surrounding wallet environment.

Still, it is a concrete example of payment infrastructure moving toward ordinary web components: a payment interaction that can be inserted into a page almost as easily as another interface element.

Developer context

Joel Dalais (@JoelDalais) is the founder of MetaNet ICU and has recently been developing several BSV applications under dalais.org. Related work includes:

• Link — the wallet/payment environment used by N-Button
• NexusNode — a channel-based messaging application with paid-entry functionality
• MetaNet ICU — a long-running BSV community and application hub

Dalais has also been publishing and working around Bitcoin projects for many years. Recent public posts show continuing development of Link, including token functionality. Metanet

Source: N-Button

Proposed BRC-248 Packages Issuer Identity Evidence for Offline Checking

Wallets & Identity

A digital item can carry an issuer identifier, but that does not necessarily mean a wallet can determine who that issuer is without querying an external indexer.

Proposed BRC-248 — Offline BAP Issuer Identity Packages attempts to make that verification material portable.

The draft, submitted by Brandon Cryderman (GenericCPU) on October 1, is designed as a companion to proposed BRC-247. BRC-247 defines a way for an asset issuer to attach an attestation based on an existing BAP identity. BRC-248 addresses the other side of the problem: carrying enough of that identity history alongside an item for a recipient to evaluate the issuer from transaction evidence rather than depending on an online identity lookup. GitHub

Its proposed identity package contains the BAP ID together with a minimal BEEF covering the relevant identity-key chain, selected ALIAS profile, profile image and applicable revocation information. The verifier can then distinguish states such as an active signing key, a retired key, a revoked identity or an unknown key at the asset’s mined height. GitHub

The proposal does not introduce a new identity system. BAP remains responsible for identity, profiles, key rotation and revocation; BRC-248 is concerned with packaging and transporting evidence from that system.

It is also early work. PR #294 remains a draft, has not completed review, and explicitly notes that even the number 248 is proposed rather than finally assigned. The draft also depends closely on BRC-247, which remains under review. GitHub

Proposed by

Brandon Cryderman (GenericCPU)

Related recent work includes:

• Proposed BRC-247 — BAP-Backed Issuer Attestation
• handcash-mpp — an unofficial open-source HTTP 402 / machine-payment package using HandCash
• BRC-248 itself currently identifies a HandCash Desktop implementation as its reference implementation

The important distinction is that these are related implementation and standards efforts; BRC-247 and BRC-248 remain draft proposals rather than established interoperability standards. GitHub

Source: Proposed BRC-248 — GitHub

BRC-135 Lets Clients Receive the Block Header Without the Rest of the Announcement

Network & Protocol

Not every network participant interested in a new block needs all of the information distributed with its announcement.

An SPV client may primarily need the block-header chain. A header archive needs the headers. A mining coordinator may need the previous-block hash and timestamp. Sending those consumers the full block-announcement payload creates unnecessary traffic and processing.

BRC-135 — Multicast Block Header Frame Format defines a smaller route.

Written by Jeff Harris, the standard takes the ordinary 80-byte BSV block header from a BRC-131 block announcement and allows an emitter to distribute it separately. One form uses a fixed 172-byte datagram—a 92-byte BRC-124-style frame plus the 80-byte header. For a dedicated stream connection, the format can become even simpler: the emitter sends the bare 80-byte headers consecutively, with no additional frame around each one. Beersy

The distinction is straightforward: a client that only needs the header should not have to receive the wider block-announcement data just to extract those 80 bytes.

BRC-135 is not a new consensus rule and does not make a header-only client equivalent to a full node. It defines how already-existing block-header information can be delivered more efficiently to consumers whose job requires that narrower data set.

Proposed by

Jeff Harris

BRC-135 sits inside a much larger multicast networking body of work. Harris is currently listed as the author of 17 BRC standards, including:

• BRC-124 — Multicast Transaction Frame Format
• BRC-126 — Multicast Transaction NACK Retransmission Protocol
• BRC-131 — Multicast Block Announcement Frame Format
• BRC-134 — Multicast Anchor Transaction Frame Format

Together, the work addresses transaction transport, loss recovery, sharding, block announcements and other parts of high-volume network distribution rather than treating BRC-135 as an isolated header format. Beersy

Source: BRC-135 — Multicast Block Header Frame Format

These three developments operate at very different layers.

N-Button asks how little work should be required to put a payment interaction on a webpage. Proposed BRC-248 asks whether issuer-identity evidence can travel with an item instead of requiring an online identity lookup. BRC-135 asks why a client that only needs an 80-byte block header should receive more network data than necessary.

What connects them is a similar engineering instinct: move only the capability, evidence or data that the next participant actually needs.

In different ways, each is trying to reduce unnecessary dependency, processing or data movement while keeping the underlying function intact.

BSV TIMES – Under the Surface

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.

Update — October 4, 2026 — Vol. 2