Wallet Infrastructure Watch / Developer Tools
In Brief
A TypeScript reference implementation of BRC-229 has been released as the public npm package @bsv/ecpm-permission-module. The module lets a supporting BRC-100 wallet multiply an arbitrary secp256k1 point by a wallet-derived secret scalar, or later remove that same scalar, without exposing the secret value to the requesting application. The capability is intended for multi-party protocols such as mental poker and verifiable shuffles, where several participants need to apply and later remove independent cryptographic masks. It operates through the existing BRC-100 getPublicKey method rather than adding a new wallet API. (npm)
News Report
The reference implementation behind BRC-229 has moved from proposal to an installable TypeScript package, giving BRC-100 wallet developers a concrete implementation of wallet-native elliptic-curve point multiplication.
The package, @bsv/ecpm-permission-module, is published under the BSV npm namespace at version 0.1.0 and identifies itself as an implementation of the BRC-229 p ecpm semantic module. Its repository points to BSV Association’s consolidated ts-stack project. (npm)
BRC-229 was published August 31 to address a narrowly defined cryptographic capability that ordinary BRC-100 key derivation does not provide.
A wallet can already derive child keys, create signatures and perform other cryptographic operations. But some multi-party protocols require a different operation: the application supplies an arbitrary elliptic-curve point, and the wallet must multiply that point by a secret scalar that remains inside the wallet. Later, the wallet may need to apply the inverse scalar to remove its own cryptographic layer. (Beersy)
The application receives only the resulting public point.
It never receives the scalar itself.
Why Ordinary Key Derivation Is Not Enough
BRC-42 and BRC-43 already let wallets derive keys within protocol-specific and counterparty-specific namespaces.
But ordinary BRC-100 getPublicKey derives a child public key relative to the standard secp256k1 generator. It does not take an arbitrary point supplied by an application and return that point multiplied by the wallet’s hidden derived scalar.
BRC-229 fills that gap.
Inside the reserved BRC-98 p ecpm namespace, a supporting wallet interprets an ordinary getPublicKey request as an elliptic-curve point-multiplication operation.
The request identifies either:
apply
or
remove
along with the supplied point and the application’s logical protocol identifier. (Beersy)
For an apply operation, the wallet derives its scalar and returns the supplied point multiplied by that scalar.
For a remove operation, it applies the modular inverse of the same scalar.
With otherwise identical derivation parameters, applying and then removing the wallet’s mask returns the original point. (Beersy)
No New BRC-100 Method
One of the more important architectural choices is that BRC-229 does not add another method to the BRC-100 interface.
Applications continue to call getPublicKey.
BRC-98 provides the reserved module namespace through which a wallet can give that existing call a specialized meaning when the ecpm module is installed. A wallet that does not support the module is expected to reject the reserved request rather than silently treating it as an ordinary key request. (Beersy)
The published TypeScript module follows that design.
A wallet host registers the module with its permission manager and supplies its ordinary key-derivation capability together with an authorization callback. The module then returns the normal BRC-100 { publicKey } result shape. (npm)
This preserves the fixed application-facing wallet interface while allowing specialized cryptographic behavior to be installed beneath it.
The Secret Stays Inside the Wallet
The package is deliberately designed so that applications never receive the key deriver or private scalar.
The caller supplies a public point. The trusted wallet module performs the multiplication internally and returns another public point. (npm)
The package also limits the module to the getPublicKey operation inside the p ecpm namespace.
That prevents the same derived ECPM scalar from being reused automatically for signatures, HMAC operations or BRC-2 encryption, which would cross protocol boundaries that BRC-229 is specifically designed to keep separate. (npm)
Point validation is similarly strict.
The specification requires compressed, lowercase secp256k1 points of the correct length and rejects malformed, non-canonical or off-curve points before multiplication. The reference package says it performs the x-coordinate range check before parsing so that a parser cannot silently reduce an invalid coordinate into a different valid point. (npm)
These checks matter because applications are allowed to choose the points being submitted to the wallet.
Multi-Party Masking
The primary example in BRC-229 is mental poker.
In a cryptographic card protocol, a card can be represented by an elliptic-curve point. Several participants can then independently apply their own secret scalar to that point.
Because scalar multiplication is commutative, the masks can be applied in different orders and later removed by their respective owners without exposing the private scalar each participant used. (Beersy)
The same primitive can support verifiable shuffles and other multi-party protocols built around successively masking shared information.
The significant property is not poker itself.
It is that an application can coordinate those operations while each participant’s secret remains inside their own wallet.
That provides a different trust model from an application generating or holding all of the cryptographic secrets itself.
Permission Handling Remains With the Wallet
The reference module also carries BRC-100 and BRC-43 permission behavior into the new operation.
Security-level-1 and security-level-2 requests can require authorization, and level 2 further scopes a grant to the counterparty. Privileged requests require explicit authorization regardless of the ordinary security level. (npm)
The package can cache applicable permission grants according to the wallet’s policy, helping protocols that may require many point operations avoid producing a permission prompt for every single point.
At the same time, unsupported or unauthorized requests fail without exposing the underlying scalar.
This means BRC-229 is not merely a mathematical helper library. It places the operation behind the wallet’s existing authorization boundary.
From Specification to Implementation
When BRC-229 first appeared, its published specification described the TypeScript implementation as proposed through bsv-blockchain/ts-stack#488.
That language remains in the current BRC text. (Beersy)
The implementation situation has now advanced beyond that description.
The npm registry exposes @bsv/ecpm-permission-module 0.1.0 as a public package, with installation instructions, wallet-permission integration, security behavior and verification commands. (npm)
Current Wallet Toolbox documentation also describes permission modules as being able to handle specialized semantic requests and specifically identifies the standalone ECPM module as the implementation demonstrating that extension. The current Wallet Toolbox release is 2.13.0. (npm)
That is the threshold that changes the editorial significance of BRC-229.
The concept is no longer represented only by a BRC document and proposed reference code. Developers can now install a named package intended to implement the specification.
BSV TIMES Read
BRC-229 is highly specialized, but the architectural idea behind it is broader.
Applications increasingly need cryptographic capabilities that go beyond paying somebody or signing a message.
The traditional response is often to give the application access to more key material.
BRC-229 takes the opposite approach.
The application receives another capability from the wallet, but the secret required to perform that capability remains behind the wallet boundary.
That separation becomes particularly useful in multi-party applications. Each participant can contribute a cryptographic operation to a shared process without handing the application the private value that makes the operation theirs.
The second notable aspect is how the feature reaches the application.
BRC-100 itself does not need another permanent method added to its interface. BRC-98 provides a reserved module mechanism through which a wallet can support specialized behavior while unsupported wallets continue to fail predictably.
That gives the wallet interface room to remain stable while implementations gain additional capabilities underneath it.
The publication of the reference module is therefore more important than another BRC number appearing in the repository.
It demonstrates the progression that matters for infrastructure: specification, implementation, installable tooling, and eventually application use.
The next threshold will be the last of those — seeing BRC-229 used by an actual multi-party application rather than primarily as a reference capability.
Source Links
@bsv/ecpm-permission-module — npm
BRC-229 — Wallet-Native Elliptic Curve Point Multiplication
Posted on September 15, 2026
Leave a comment