1Color Wallet Module v0.2.0 Adds Support for Asset Processing Rules

Developer Tools / Wallets & Identity

In Brief

Version 0.2.0 of @bsv/color-permission-module has been published with support for additional processing rules declared by 1Color assets.

Wallet developers can register implementations of those rules, including issuer requirements, while the module rejects assets whose required profiles or versions it cannot support. Related templates, Mandala and Expo wallet toolbox packages were also published on October 30.

News Report

npm records show @bsv/templates 2.2.0 published on October 30 at 03:58 UTC and @bsv/color-permission-module 0.2.0 at 04:17 UTC. The main implementation contribution, pull request #1334 in the BSV TypeScript Stack repository, merged at 02:20 UTC.

Related releases followed with @bsv/expo-wallet-toolbox 0.22.0 at 04:52 UTC and @bsv/mandala 0.5.0 at 04:54 UTC.

1Color, specified in BRC-162, encodes fungible token balances in transaction outputs. BRC-207 defines how wallets handle those assets. The new module support concerns wallet processing on BSV Blockchain; it does not change the blockchain’s consensus rules.

Enforcing an Asset’s Declared Requirements

A processing profile describes additional rules a wallet must understand before handling an asset. Its declaration identifies an exact version and parameters, allowing different assets to require different handling.

The requirements originate in the asset’s deployment transaction and remain attached to its identity. A later transfer cannot remove them by omitting the declaration or substituting different requirements.

The module now lets the wallet host register handlers for supported profiles and provide durable storage. It checks that every required profile and version is supported before running any handler. Unsupported requirements cause the operation to fail.

Handlers can validate parameters and output data, select the asset’s overlay provider, restrict operations and decide whether a received output can be accepted. An overlay is a service that tracks admission and spendability under the asset’s rules.

Templates 2.2.0 supplies the corresponding attribute reader, including required-profile declarations and profile-defined output data. It distinguishes absent attributes from malformed reserved fields inside an otherwise valid payload map.

Keeping Issuer Evidence in the Wallet Host

Mandala 0.5.0 supplies a concrete integration through its issuer-v1 profile. Mandala is an issuer layer built on 1Color’s token format.

Its wallet-side library verifies issuer-overlay admission evidence and records the result in a ledger controlled by the wallet host. The profile handler uses that record when deciding whether to accept a receipt.

The implementation distinguishes settled receipts from pending offline receipts. Its offline path performs separate evidence checks, with later overlay admission needed to settle the pending receipt.

The generic module provides a host-only markSettled method. Applications cannot call it through the BRC-100 interface. Custody receipts remain ordinary BRC-207 JSON within the 1,000-byte limit; the issuer’s evidence is handled separately.

Published Components and Integration Limits

The Expo wallet toolbox publication includes the related wallet integration. Desktop integration also merged, but the latest published BSV Desktop release remained v3.3.1 at the time of checking. A merged contribution does not establish a new downloadable desktop release.

Mandala 0.5.0 has a significant compatibility boundary: its documentation says older derivations, baskets, message bodies and topics are refused rather than automatically converted. Developers adopting it need to account for that break.

The generic color module does not itself carry or validate token history. Its ordinary processing relies on overlay admission and spendability, while profiles requiring other evidence depend on their own libraries and trusted providers.

The TypeScript contribution’s hosted build, test and lint checks passed. BSV TIMES checked the published package archives against their registry integrity records and reviewed the source and integration notes. It has not independently tested a live transfer. The Mandala contribution also identifies a full round trip through a running overlay and MessageBox as not yet exercised live.

BSV TIMES Read

The practical advance is a reusable way for wallets to enforce requirements attached to an asset, beyond recognizing its token format and balance.

That can reduce repeated integration work while keeping responsibility explicit: the asset declares its requirements, the wallet registers supported implementations, and unsupported operations are refused.

The publication moves this work into installable developer components. Broader wallet availability and demonstrated interoperability remain separate milestones.

Developer Context

Darren “Deggen” Kellenschwiler, whose GitHub account is sirdeggen, authored the module contribution and the related Mandala and wallet integrations.

BRC-162 names Kellenschwiler and David Case as authors. BRC-207 was authored by Ty Everett and Case, with Kellenschwiler listed among its contributors.

Source Links

Posted on October 30, 2026 (UTC)