Coder Legion - Recent posts tagged bitcoin

Crypto Real Estate Swap

Wed, 02 Sep 2026 00:15:09 +0000

Salaam! Crypto holders such as COBOL and Fortran IBM Watson array rig operators can go to eBay and buy real estate and pay with crypto perhaps but it is against the rules. Also, it is not all online and the properties may not be high quality. Therefore, we decided to add a platform where crypto adopters can acquire farms, vineyards, houses and more with a simple click! No more waiting for realtors to call back, now it is buy now and most tokens are accepted. What is different from eBay? High quality only, no scams. Crypto tool.

How does it work? Visitors simply browse listings and click buy now then fill out a short form and the deed is mailed to them. This fills a gap in the real estate automation and crypto markets. Java and HTML allow users to push buttons and create a listing or research parcel maps using custom functions like:

function gazaPeace() {
if (land < house) {
......

As many insiders know, buying and selling real estate can be a chore especially if paying in DOGE or Tron. Our platform from Moonshee International is a nice solution to a huge problem in the market.

The tool works as a website and has animations and many special features like user settings. We prefer to launch webtools because they work on almost all devices except 3270 and Amiga along with C128. Apple is supported along with Linux, Cobol emus and Fortran terminals.

We used unFreeze tool make animated gifs and used scrolling effects as well to make the site feel alive. We also added a special feature which shows gems and rings, money falling from the sky like rain. Feel free to add your listings or borrow the template. To run it, use a browser on any smart phone or terminal.

In Hong Kong we havre a lot of unhoused residents. We need disruptive solutions to get people housed including the power of crypto. With our platform, people can buy land and donate to homeless, deploy their crypto in a new way. Or buy 10 lots for themselves and one for homeless, it is purely optional. We used AGS to help with the animation and testing. Made on recycled computer running 32 bits on an AMD processor with Linux and COBOL flowchart style. CSS was key to project success. One problem we had when developing was bandwith constraints. Other than that the wi-fi in Kowloon Harbour was fluid. We avoided using built in translators for this suite because of the heavy Java animations which trip up our translator module.
Waheguru.

Engineering a Non-Custodial Bitcoin Paywall for an AI Assistant

Mon, 31 Aug 2026 07:12:12 +0000

Engineering a Non-Custodial Bitcoin Paywall for an AI Assistant

We recently completed the first real Bitcoin payment for Zorgax, the AI assistant inside the MyZubster ecosystem.

The goal was not simply to display a wallet address. We wanted a complete production flow that could connect a verified on-chain payment to an authenticated account and automatically activate paid features.

The final lifecycle looks like this:

Authentication
      ↓
Payment intent
      ↓
External Bitcoin wallet
      ↓
Blockchain transaction
      ↓
Independent verification
      ↓
Entitlement activation
      ↓
Backend feature access

Zorgax access levels

Zorgax currently provides three plans:

Free
- Basic AI assistant
- Limited web research
- Maximum 2 sources

Pro — €9.90 monthly equivalent
- Advanced web research
- Maximum 5 sources
- Zorgax workspace

Developer — €29.90 monthly equivalent
- Everything in Pro
- Maximum 8 sources
- Direct API access
- Automation features

The current Bitcoin flow creates time-bounded access. It is not an automatic recurring wallet subscription.

Why a wallet address is not enough

A public Bitcoin address can receive payments, but it cannot answer several application-level questions:

Which account made the payment?
Which plan was selected?
What BTC amount was expected?
When was the exchange-rate quote generated?
Has this transaction already been used?
When should the entitlement expire?

For this reason, Zorgax creates a persistent payment intent before displaying the payment instructions.

{
  "intentId": "payment-intent-id",
  "ownerId": "authenticated-user",
  "plan": "pro",
  "asset": "BTC",
  "destination": "bitcoin-address",
  "expectedAmountSats": 14728,
  "status": "PENDING",
  "expiresAt": "quote-expiration"
}

The exact amount varies according to the quote generated for the order.

Creating the checkout

The authenticated frontend requests a new payment intent:

const response = await fetch(
  "/api/zorgax/assistant/checkout/intent",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`
    },
    body: JSON.stringify({
      plan: "pro",
      asset: "BTC"
    })
  }
);

The backend associates the intent with the current user and returns:

The BTC destination
The exact amount
The expiration time
The payment-intent identifier

The user then pays from an external wallet.

MyZubster never requests the private key and never signs or broadcasts the transaction.

Verifying the transaction

After broadcasting the payment, the user receives a Bitcoin transaction ID.

The TXID is submitted to the verification endpoint:

await fetch(
  `/api/zorgax/assistant/checkout/intent/${intentId}/verify`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`
    },
    body: JSON.stringify({
      paymentReference: txid
    })
  }
);

The server then retrieves the public transaction and checks:

Transaction exists
        ↓
Correct destination
        ↓
Sufficient amount
        ↓
Required confirmations
        ↓
Intent belongs to the user
        ↓
Payment has not already been consumed

A simplified verifier looks like this:

const transaction = await getBitcoinTransaction(txid);

const output = transaction.outputs.find(
  item => item.address === intent.destination
);

if (!output) {
  throw new Error("Unexpected payment destination");
}

if (output.value < intent.expectedAmountSats) {
  throw new Error("Insufficient payment amount");
}

if (transaction.confirmations < minimumConfirmations) {
  throw new Error("Insufficient blockchain confirmations");
}

Why confirmations matter

During the first live production test, Zorgax detected the transaction while it was still in the mempool.

The application returned:

Payment not activated:
Insufficient blockchain confirmations

This was expected.

Seeing a transaction in the mempool does not mean the system should immediately grant paid access. Zorgax waited until the payment entered a Bitcoin block.

After the required confirmation, the same TXID was verified again:

Payment verified
Access ACTIVE
Plan Pro

No second payment was required.

Activating the entitlement

After successful verification, Zorgax creates or updates the account’s entitlement:

{
  "plan": "pro",
  "tier": "PRO",
  "status": "ACTIVE",
  "source": "BITCOIN_PAYMENT",
  "startsAt": "activation-date",
  "expiresAt": "expiration-date"
}

Every protected request evaluates this access state before running the requested operation.

Enforcing access on the backend

Hiding a button in the frontend is not security.

The backend applies an access policy to every Zorgax request:

const policies = {
  guest: {
    chat: true,
    webResearch: false,
    workspace: false,
    directApi: false
  },

  free: {
    chat: true,
    webResearch: true,
    maxWebResults: 2,
    workspace: false,
    directApi: false
  },

  pro: {
    chat: true,
    webResearch: true,
    maxWebResults: 5,
    workspace: true,
    directApi: false
  },

  developer: {
    chat: true,
    webResearch: true,
    maxWebResults: 8,
    workspace: true,
    directApi: true
  }
};

For example, direct research requires the Developer tier:

router.get(
  "/research",
  authenticate,
  requireZorgaxPlan("developer"),
  researchHandler
);

Workspace persistence requires Pro or higher:

router.post(
  "/data/commit",
  authenticate,
  requireZorgaxPlan("pro"),
  commitHandler
);

Guest access without silent authentication failures

Zorgax supports guest chat, but an invalid token must never silently become a guest session.

The authentication boundary is:

No token
→ Guest access

Valid token
→ Authenticated access

Invalid token
→ 401 Unauthorized

This distinction prevents expired or manipulated credentials from bypassing protected logic.

Unifying legacy subscriptions and new entitlements

MyZubster already had legacy subscription records. The new payment implementation introduced a more explicit entitlement model.

We created one access service that evaluates both:

Legacy subscriptions ─┐
                      ├── Unified Zorgax access
New entitlements ─────┘

The service selects the highest active plan and returns a single feature policy.

This allows existing accounts to remain compatible while new Bitcoin payments use the improved lifecycle.

A Vercel routing problem

The application also contains a generic Zorgax AI gateway route.

A broad rule such as:

/api/zorgax/*

could intercept requests intended for the monetization backend.

The specific monetization route now takes priority:

{
  "source": "/api/zorgax/monetization/(.*)",
  "destination": "/api/index.js"
}

Only afterward does the generic AI proxy apply.

This ensures that purchases and entitlements are handled by the backend containing the correct authentication middleware and database connection.

Confirming persistent AI writes

Zorgax can prepare structured data, but it does not silently persist AI-generated content.

The workspace flow requires:

A generated preview.
A cryptographic digest of that preview.
An explicit user confirmation.
Digest validation before persistence.

const expectedDigest = digestPreview(preview);

if (expectedDigest !== submittedDigest) {
  throw new Error("Preview changed");
}

This creates a clear boundary between AI suggestions and authorized writes.

Production verification

Before deployment, the Zorgax test family completed:

58 test suites
206 tests passed

Production checks confirmed that:

Public pricing                  → 200
Guest chat                      → 200
Guest web research              → disabled
Protected monetization routes   → 401 without login
Developer research API          → 401 without login
Checkout                        → 401 without login

The real Bitcoin transaction then proved the final missing part: verified payment-to-entitlement activation.

Security boundaries

The production design follows these rules:

No private keys are accepted.
MyZubster does not sign transactions.
Users pay from external wallets.
The destination and amount are verified.
Blockchain confirmations are required.
Payment intents belong to authenticated users.
Paid features are enforced server-side.
Persistent writes require explicit confirmation.
Invalid tokens never become anonymous sessions.

What comes next

The current system is operational but intentionally conservative.

Possible next improvements include:

Renewal notifications
Payment-history dashboards
Downloadable receipts
Additional independent Bitcoin providers
More supported settlement assets
Entitlement-expiration reminders
Better transaction monitoring

Every new asset will require its own trusted quote source, verification logic and confirmation policy.

Final result

Zorgax monetization is no longer only a pricing page.

A real production payment successfully completed this sequence:

BTC payment
→ blockchain confirmation
→ independent verification
→ entitlement activation
→ Pro features enabled

The result was:

Access: ACTIVE
Plan: Pro

Project links

Zorgax:

https://www.myzubster.com/zorgax

MyZubster source code:

https://github.com/MyZubster-Ecosystem/myzubster

Production monetization implementation:

https://github.com/MyZubster-Ecosystem/myzubster/commit/d7a579cd89801d29ac094a19af42fb17350691ef

We Completed the First Live Bitcoin-to-Pro Activation on MyZubster

Mon, 31 Aug 2026 07:04:21 +0000

We Completed the First Live Bitcoin-to-Pro Activation on MyZubster

Today we reached a major milestone: Zorgax successfully processed a real Bitcoin payment and activated Pro access in production.

This was a complete end-to-end test, not a simulated checkout.

The production flow was:

MyZubster login
      ↓
Zorgax payment intent
      ↓
External Bitcoin wallet
      ↓
On-chain transaction
      ↓
Blockchain confirmation
      ↓
Independent verification
      ↓
Pro access activated

What is Zorgax?

Zorgax is the AI assistant inside the MyZubster ecosystem.

It combines:

General AI assistance
Web research
Source collection
Structured-data preparation
Workspace features
Developer APIs
Bitcoin-based access activation

The available plans are:

Free       €0
Pro        €9.90
Developer  €29.90

Free users receive limited research, Pro users gain workspace features and additional sources, while Developer accounts can access automation and direct APIs.

A non-custodial payment architecture

MyZubster does not request, store or manage users’ private keys.

Users send Bitcoin through their own external wallet. Zorgax only creates a payment intent and records:

The selected plan
The expected BTC amount
The destination address
The expiration time
The submitted transaction ID
The verification status

The backend then verifies the public transaction independently.

A simplified version of the process looks like this:

const payment = await verifyTransaction(txid);

if (payment.destination !== intent.destination) {
  throw new Error("Unexpected payment destination");
}

if (payment.amount < intent.expectedAmount) {
  throw new Error("Insufficient payment amount");
}

if (payment.confirmations < minimumConfirmations) {
  throw new Error("Insufficient blockchain confirmations");
}

await activateEntitlement({
  ownerId: intent.ownerId,
  plan: intent.plan,
  status: "ACTIVE"
});

The application never signs or broadcasts a transaction.

Waiting for blockchain confirmation

During the live test, Zorgax detected the transaction but initially returned:

Payment not activated:
Insufficient blockchain confirmations

This was the expected behavior.

The system did not activate Pro access simply because a valid-looking TXID had been submitted. It waited until the transaction had the required blockchain confirmation.

After confirmation, we submitted the same TXID again:

Payment verified
Access ACTIVE
Plan Pro

Backend access enforcement

We also implemented server-side feature enforcement.

Guest
- Basic chat
- No live web research

Free
- Limited research
- Maximum 2 sources

Pro
- Advanced research
- Maximum 5 sources
- Zorgax workspace

Developer
- Higher limits
- Automation
- Direct research API

These restrictions are enforced by the backend, not only hidden in the user interface.

Protected endpoints return authentication or payment-required responses when the account does not have the necessary plan.

Fixing a production routing problem

During implementation, we discovered that the generic Zorgax gateway could intercept monetization requests.

The Vercel routing order was corrected so that:

/api/zorgax/monetization/*

is processed by the authenticated MyZubster backend before the generic AI proxy route.

This ensures that purchases, subscriptions and entitlements use the correct database and authentication middleware.

Unifying subscriptions and entitlements

The project contained both legacy subscription records and newer entitlement records.

We introduced a unified access service that:

Checks both stores.
Selects active records.
Chooses the highest available plan.
Fails safely when access cannot be verified.
Returns a single policy to every Zorgax endpoint.

This keeps older subscriptions compatible with the new payment system.

What the live test proves

The successful transaction proves that the following components work together in production:

Authentication
Payment-intent generation
BTC amount calculation
External wallet payment
TXID submission
Destination validation
Amount validation
Confirmation validation
Database persistence
Pro entitlement activation
Feature-access enforcement

It transforms Zorgax monetization from a pricing interface into a functioning production system.

Current boundaries

The first release intentionally remains conservative:

Bitcoin is currently the operational settlement asset.
Payments are non-custodial.
Private keys are never accepted.
Access activation requires independent verification.
Automatic recurring billing is not currently enabled.

Future work can add renewal notifications, payment dashboards, downloadable receipts and more independent blockchain providers.

Explore the project

Zorgax:

https://www.myzubster.com/zorgax

MyZubster repository:

https://github.com/MyZubster-Ecosystem/myzubster

Production monetization update:

https://github.com/MyZubster-Ecosystem/myzubster/commit/d7a579cd89801d29ac094a19af42fb17350691ef

The next goal is to make the complete payment and entitlement lifecycle easier to monitor while preserving the non-custodial design.

# We Built a Safer Bitcoin Payment Layer for Zorgax — Here's What We Learned

Sat, 29 Aug 2026 06:45:23 +0000

We Built a Safer Bitcoin Payment Layer for Zorgax — Here's What We Learned

Adding Bitcoin to an application sounds simple.

Generate an address, wait for a transaction, verify the amount, unlock the service.

In a prototype, that might be enough.

In a system designed around AI agents and autonomous infrastructure, it isn't.

We've been working on the Bitcoin payment layer for Zorgax, the AI and knowledge component of the MyZubster ecosystem.

The latest implementation milestone is now complete locally:

60 test suites. 208 tests. All passing.

But the more interesting part isn't the test count.

It's what we had to design around.

One Checkout, One Bitcoin Address

The first architectural decision was to avoid using a single Bitcoin address for every payment.

Each checkout intent receives a different address derived from an Electrum-compatible watch-only wallet.

Payment Intent #001
        ↓
    Address A

Payment Intent #002
        ↓
    Address B

Payment Intent #003
        ↓
    Address C

This gives us a much cleaner relationship between an intent and its blockchain activity.

Instead of asking:

Which customer sent this transaction?

we already have a strong association between the destination address and the checkout.

It also avoids unnecessarily reusing the same public address across unrelated payments.

The Application Doesn't Need the Spending Keys

A payment service needs to observe money.

It doesn't necessarily need permission to spend it.

That's why the architecture uses a watch-only boundary.

             ZORGAX

                ↓

        Watch-Only Wallet

                ↓

              XPUB

                ↓

       Address Derivation

                ↓

       Blockchain Monitoring

The application can derive and monitor addresses without holding the corresponding private spending keys.

That's an important security boundary.

If the web application doesn't need the capability to spend funds, we shouldn't give it that capability.

Bitcoin Amounts Are Integers

Another rule: don't make financial correctness depend on floating-point arithmetic.

Bitcoin gives us a convenient smallest unit:

1 BTC = 100,000,000 satoshis

So internally we verify integer satoshi values.

Instead of reasoning about:

0.00125000 BTC

the system can reason about:

125000 sats

Expected amount:

Received amount:

Comparison:

125000 == 125000

Boring?

Absolutely.

That's exactly what I want from payment arithmetic.

Distributed Systems Retry Everything

Then we reach one of the more important problems.

Imagine the blockchain watcher detects a transaction.

It sends the event to the application.

The application processes it successfully.

But the acknowledgement gets lost.

The watcher retries.

Without protection:

TX detected
    ↓
Payment processed
    ↓
Network problem
    ↓
Retry
    ↓
Payment processed AGAIN

That's unacceptable.

So transaction processing needs to be idempotent.

The TXID becomes part of that boundary.

Incoming TXID
     ↓
Already processed?
   ↙             ↘
 YES             NO
  ↓               ↓
Stop            Verify
                  ↓
                Record

The same blockchain transaction should not create multiple economic effects because a distributed system retried a message.

Valid Doesn't Mean Valid Everywhere

There's another subtle distinction.

A real Bitcoin transaction can be perfectly valid on-chain and still be invalid for a particular checkout.

That's why we also need anti-replay protections.

Payment verification isn't simply:

Is this TX valid?

It is closer to:

Does this transaction
        ↓
belong to this payment intent
        ↓
for this derived address
        ↓
for this expected amount
        ↓
and has it already been consumed?

The transaction has context.

That's especially important once machines start consuming payment APIs automatically.

Database State Is Part of the Deployment

Payment systems don't live entirely inside application code.

Adding new payment behavior changes persisted state too.

For Zorgax, that means MongoDB migration needs to be treated as an explicit deployment operation.

Not:

git push
   ↓
hope

But:

Code
 ↓
Tests
 ↓
Review
 ↓
Migration Plan
 ↓
Infrastructure Check
 ↓
Database Migration
 ↓
Deployment
 ↓
Enable Rail

The migration should be controlled independently from writing the feature.

Feature Flags Are Security Features Too

The Bitcoin rail currently remains disabled.

Not because the implementation hasn't been tested.

Because the surrounding production infrastructure isn't ready yet.

The code still needs production dependencies such as the watch-only wallet XPUB and a reachable Electrum boundary through appropriately protected infrastructure.

This gives us an important rule:

CODE COMPLETE

     ≠

PRODUCTION READY

A payment feature shouldn't become active just because somebody merged the code.

Infrastructure readiness is part of feature readiness.

Where We Are Now

The current local milestone includes per-intent Electrum watch-only addresses, anti-replay protection, TXID idempotency, integer satoshi verification and a controlled MongoDB migration path.

The implementation currently passes:

60 test suites
208 tests
──────────────
ALL PASSING

The generated patch was also checked using:

git apply --check

But no production commit, push, deployment, real database migration or Bitcoin transaction was performed as part of this milestone.

That distinction matters.

Why Are We Doing This Inside an AI Project?

Because Zorgax isn't intended to remain only a chatbot.

We're exploring what happens when AI systems become capable of interacting with services and infrastructure.

Eventually an agent might need to purchase something.

Maybe compute.

Maybe an API request.

Maybe access to a specialized dataset.

Maybe a physical service.

The workflow starts looking like this:

AI Agent
   ↓
Needs Resource
   ↓
Requests Service
   ↓
Receives Payment Intent
   ↓
Payment
   ↓
Verification
   ↓
Resource Unlocked

Now the payment layer becomes part of agent architecture.

Machine Payments Change the Threat Model

Humans are relatively slow.

Agents aren't.

An automated agent could make hundreds of requests, retry failed operations and coordinate multiple services simultaneously.

That means payment infrastructure designed for agents has to assume automation from the beginning.

          AI AGENT
              ↓
       Payment Intent
              ↓
      Per-Intent Address
              ↓
            BTC
              ↓
           Electrum
              ↓
     Blockchain Detection
              ↓
       Verification Layer
        ↙      ↓       ↘
    Amount    TXID    Intent
      ↓        ↓        ↓
    sats   idempotent  replay
              ↓
        Payment State
              ↓
          SERVICE

This is where payments stop being just a UI problem.

They become a distributed-systems problem.

The Bigger Experiment

Bitcoin checkout is useful by itself.

But we're interested in what comes after it.

Imagine autonomous software where:

Agent A
   ↓
discovers
   ↓
Service B
   ↓
requests price
   ↓
Payment Intent
   ↓
settlement
   ↓
verification
   ↓
service delivered

No shopping cart.

No human clicking "Pay Now."

Potentially no traditional account relationship between the two systems.

Just protocols.

That creates a much larger engineering question:

What does payment infrastructure look like when the customer is software?

We don't have the complete answer yet.

But building the boring pieces correctly — integer amounts, idempotency, replay protection, isolated payment intents, watch-only wallets and controlled migrations — is probably where it starts.

Because autonomous payments won't become reliable by making agents smarter.

They'll become reliable by making the infrastructure underneath them predictable.

If you were designing payments specifically for autonomous AI agents, what would you prioritize first: Bitcoin, Lightning, stablecoins, traditional APIs, or protocol-native payments?

From a Bitcoin Transaction to a Paid AI Subscription — Without Holding Private Keys

Fri, 28 Aug 2026 16:17:18 +0000

From a Bitcoin Transaction to a Paid AI Subscription — Without Holding Private Keys

Building a paid AI assistant sounds straightforward.

Define a price, add a checkout button, verify the payment, and unlock the premium features.

But when we started building the monetization layer for Zorgax, the AI assistant inside MyZubster, one question quickly became more important than the pricing itself:

How can an application verify a cryptocurrency payment without becoming a custodian of the user's funds?

That question has shaped the latest development of Zorgax.

The goal

Zorgax currently has three planned access levels:

Zorgax Free, Zorgax Pro (€9.90 monthly equivalent) and Zorgax Developer (€29.90 monthly equivalent).

The broader payment architecture is designed around multiple crypto assets, including BTC, ETH, XMR and TARI.

But there is an important rule:

Zorgax should coordinate and verify payments — not control the user's wallet.

That means no seed phrases in the application.

No private keys in the frontend.

No transaction signing by Zorgax.

A payment button isn't enough

Imagine a user selects Zorgax Pro and chooses Bitcoin.

The application knows:

Plan: Zorgax Pro
Price: €9.90
Asset: BTC

A server-side quote can calculate the corresponding BTC amount.

The naive approach would then be to trust information coming back from the client:

"I paid this address."
"This is the amount."
"This is my transaction."
"Activate my subscription."

That's exactly what we don't want.

A client should never be the authority deciding what it was supposed to pay.

So we introduced another layer.

The Payment Intent

Before the user pays anything, Zorgax creates a persistent Payment Intent.

It records information such as:

intent ID
authenticated owner
selected plan
crypto asset
destination address
expected crypto amount
EUR value
quote timestamp
expiration
settlement status

The important part is that this information is stored server-side.

Later, when the user provides a blockchain transaction reference, the backend doesn't ask the browser:

“How much were you supposed to pay?”

It already knows.

The architecture becomes:

User
↓
Authenticated Checkout
↓
Server-side Crypto Quote
↓
Persistent Payment Intent
↓
External Wallet Payment
↓
Trusted Blockchain Verifier
↓
Verified Payment
↓
Active Subscription

This changes the trust model considerably.

Bitcoin became our first real test

For Bitcoin, we built a small verification service around Electrum.

The service runs separately from the application and doesn't need to sign transactions.

Its job is much narrower:

inspect a transaction and report what actually happened on the blockchain.

While testing against Electrum 4.8.1, we discovered an important implementation detail.

We initially expected:

gettransaction

to give us a conveniently decoded transaction.

Instead, the real Electrum CLI returned the serialized transaction.

So the verifier had to evolve.

The flow became:

TXID
↓
gettransaction
↓
raw transaction
↓
deserialize
↓
outputs
↓
address + value_sats

Confirmations are obtained separately through:

get_tx_status

This is one reason I like developing infrastructure in the open.

The repository doesn't just show the final design.

It also shows where assumptions met reality.

Satoshis instead of guessing units

Another useful result of decoding the transaction is that Electrum exposes output values explicitly as satoshis.

Conceptually:

{
"address": "bc1q...",
"value_sats": 7212
}

That lets the verifier perform the critical comparison using integers:

paid satoshis >= expected satoshis

instead of relying on floating-point BTC arithmetic or guessing units.

For payment verification, small details like this matter.

A transaction isn't automatically a payment

Finding a transaction containing the expected address and amount still isn't enough.

We also need confirmation policy.

A transaction with:

confirmations: 0

may exist in the mempool, but the trusted payment layer can require a minimum number of confirmations before granting access.

Only after verification succeeds can Zorgax move toward:

PENDING
↓
VERIFIED
↓
ACTIVE

where ACTIVE refers to the subscription access, not simply the existence of a transaction.

Preventing one transaction from becoming many subscriptions

There is another less visible problem: replay.

Suppose someone takes one valid Bitcoin transaction and submits its TXID multiple times.

Without protection, the same economic event could potentially be used to activate several subscriptions.

So the payment-intent architecture also tracks consumed payment references and introduces uniqueness constraints around them.

A verified transaction should represent one settlement event, not an unlimited activation token.

Payment intents expire too

Crypto prices change continuously.

For that reason, the current checkout architecture uses short-lived quotes.

A Payment Intent currently has a 15-minute lifetime.

If it expires before settlement, it shouldn't remain a permanent promise to accept the original crypto amount.

The user can simply request a new quote and create a new intent.

What Zorgax never needs

The interesting result is what this architecture does not require.

Zorgax doesn't need the user's:

seed phrase
private key
wallet password
spend key

The user can pay from an external wallet.

The blockchain verifier observes the result.

The application decides whether that external event satisfies an internally stored Payment Intent.

That's a very different model from embedding a cryptocurrency wallet directly inside an AI application.

Beyond Bitcoin

Bitcoin is currently serving as our clearest implementation example, but the architecture is intended to be chain-independent.

Conceptually:

              Payment Intent
                   ↓
           Verification Layer
          /       |       |       \
        BTC      ETH     XMR      TARI
         ↓
      Electrum

Each blockchain can have a different verifier behind the same general boundary.

This is especially important for Monero.

Because of Monero's privacy properties, its verification model cannot simply copy the assumptions used for transparent Bitcoin transactions.

The common abstraction should stay the same while chain-specific verification remains isolated.

Connecting this to the MyZubster Marketplace

The same idea extends beyond Zorgax subscriptions.

MyZubster's Marketplace is experimenting with a broader economic layer involving:

BTC, ETH, XMR, TARI, MYZ, barter and free exchanges.

The underlying principle remains:

The platform can coordinate economic activity without needing custody of users' private keys.

Zorgax monetization gives us a concrete environment in which to test that principle.

What is actually finished?

It's important not to confuse architecture with production readiness.

We now have several important building blocks: subscription plans, server-side crypto quoting, trusted verification boundaries, the BTC/Electrum verifier, persistent Payment Intents, expiry and replay protections, and the connection between verified payments and subscription activation.

But the complete system still needs production configuration, live end-to-end deployment testing and further operational hardening.

The other chains also need their own production-grade verification paths.

So this isn't a “payments are finished” announcement.

It's a development update.

The architecture we're moving toward

The final flow is becoming increasingly simple to describe:

Choose Plan

↓

Create Payment Intent

↓

Pay From External Wallet

↓

Verify Blockchain Transaction

↓

Match Transaction to Intent

↓

Activate Subscription

And underneath that flow is one rule that we don't want to compromise:

Verify the payment without owning the money.

For me, that's becoming one of the more interesting parts of building Zorgax.

Not simply teaching an AI assistant how to answer questions, but connecting software, identity, economic events and permissions while keeping the trust boundaries explicit.

The system is still evolving.

And, as with the rest of MyZubster, we're building it in the open.

Project links

MyZubster core:
github.com/MyZubster-Ecosystem/myzubster

Zorgax trusted payment verification — PR #814:
PR #814

Bitcoin/Electrum verifier — PR #815:
PR #815

Electrum 4.8.1 hardening — PR #817:
PR #817

Persistent Payment Intents — PR #818:
PR #818

MyZubster Marketplace:
github.com/MyZubster-Ecosystem/MyZubster-Marketplace

Why I love this new Bitcoin use case, and what you guys think?

Tue, 14 Jul 2026 04:10:51 +0000

I recently came across an incredibly creative application of blockchain technology: Blockonomics' FIFA 2026 Global Fan Wall: https://insights.blockonomics.co/put-your-fifa-2026-world-cup-memory-on-the-global-fan-wall-for-eternity/

It’s refreshing to see Bitcoin being used for something beyond just financial transactions.

What do you guys honestly think of this?

Demystifying the Bitcoin Lightning Network: A Technical Deep Dive from a Bootcamp Hackathon

Sat, 04 Jul 2026 06:34:22 +0000

Last week, I had the incredible opportunity to transition from a Bitcoin beginner to building a Layer 2 solution in less than 12 hours at the Kisumu Lightning Network Bootcamp hosted by Zone01 Kisumu.

While most articles explain the Lightning Network (LN) abstractly as "fast and cheap," I will break down the technical mechanisms;the actual cryptographic primitives and scripts that make trustless, off-chain Bitcoin transactions possible today. All from what I learnt from the 5-day bootcamp.

The Core Primitive: Bidirectional Payment Channels

At its foundation, the Lightning Network is a peer-to-peer network of bidirectional payment channels. It avoids blockchain congestion by shifting transactions off-chain, using the underlying base layer strictly as a final settlement layer.

A channel is established when two nodes execute an on-chain Funding Transaction.

The Funding State
2-of-2 Multi-Signature UTXO: Both participants lock up an agreed amount of Bitcoin into a multisig address. This requires signatures from both parties to move funds.
Commitment Transactions**: Before broadcasting the funding transaction to the blockchain, both parties sign an asymmetric, unbroadcasted
Commitment Transaction. This acts as a
balance sheet of the current channel state.

From a total beginner to atleast an intermediate knowledgeable person in regards to bitcoin,this was a great learning experience for me and I'm so grateful to the organizers and facilitators of this intensive bootcamp.

Unboxing My New OneKey Classic 1S Hardware Wallet

Tue, 19 May 2026 13:57:58 +0000

There are moments in crypto when you realize that security is no longer optional — it becomes a responsibility.

After spending years working with blockchain infrastructure, nodes, wallets, and decentralized systems, I finally decided to move part of my operational environment toward a dedicated hardware wallet experience.

And honestly… I did not expect the experience to be this good.

First Impressions

The first thing that surprised me about the OneKey Classic 1S was the packaging quality.

Everything arrived professionally sealed and protected, giving a very strong first impression focused on authenticity and tamper protection. In a market where hardware wallet trust is everything, details like this matter much more than people think.

The packaging feels premium without being unnecessarily excessive.
Minimalistic. Clean. Professional.

You immediately notice that security was considered from the very beginning of the user experience.

Security Seals & Packaging Quality

One of the biggest concerns when purchasing a hardware wallet is whether the device could have been manipulated before arrival.

Fortunately, the OneKey Classic 1S arrived:

Completely sealed
Properly protected
Professionally packaged
With visible security-focused presentation

The unboxing experience genuinely felt closer to opening a high-end security device than a simple crypto accessory.

That matters.

Especially today.

Setup Experience

I expected the installation process to be complicated or technical.

It wasn't.

The wallet initialization and software setup process was relatively simple and intuitive.

The official OneKey software guided the entire process step-by-step, including:

Wallet creation
Recovery phrase backup
Device verification
Security confirmation
Connection process

Even for users who are not deeply technical, the experience feels approachable and clean.

Build Quality

The device itself feels solid and surprisingly lightweight.

The physical buttons are responsive, the screen is clear, and the overall design has a professional aesthetic that feels modern instead of outdated.

Some hardware wallets still look and feel experimental.

The OneKey Classic 1S does not.

It feels polished.

Why This Matters

In recent months, the crypto ecosystem has seen increasing concerns related to:

Wallet compromises
Malicious smart contracts
Fake applications
Phishing attacks
Blind signing risks

Because of that, I started looking more seriously into dedicated cold-storage solutions with:

Strong security architecture
Transparent development
Open-source firmware
Clear signing support
Modern ecosystem compatibility

The OneKey ecosystem checked many of those boxes.

Final Thoughts

The truth is simple:

I expected a decent hardware wallet.

What I received was a much more polished experience than anticipated.

From the packaging quality to the onboarding process, the OneKey Classic 1S gave a very strong first impression.

For anyone looking to improve their crypto security setup while keeping usability simple, this device is definitely worth researching.

Official Link + 10% Discount

If you want to check the device directly from the official website, you can use my referral link here:

https://onekey.so/r/MUGY73

You can also use the discount code:

MUGY73

to receive 10% OFF on your purchase directly from the official OneKey website.

UltrafastSecp256k1 v4.0 — Optional Secondary secp256k1 Backend for Evaluation

Sun, 17 May 2026 00:46:15 +0000

Overview
UltrafastSecp256k1 v4.0 is a high-performance secp256k1 engine built for evaluation as an optional secondary backend for Bitcoin Core. The goal is not to replace libsecp256k1, but to make it possible to measure, compare, and selectively enable an alternative implementation under controlled conditions.

This post presents the current state of the project, its integration model, and the evidence gathered through continuous audit infrastructure.

Repository: https://github.com/shrec/UltrafastSecp256k1 Release v4.0.0: https://github.com/shrec/UltrafastSecp256k1/releases/tag/v4.0.0

Integration Model
Integration uses a shim layer that exposes the identical secp256k1.h API surface. Bitcoin Core can be built with the alternative backend using a single CMake flag:

cmake -B build -DSECP256K1_BACKEND=ultrafast
cmake --build build
The default backend remains libsecp256k1 unchanged. All existing Bitcoin Core C++ source files remain unmodified — only the CMake build system references a different library.

Fork demonstrating this integration: https://github.com/shrec/bitcoin/tree/feature/ultrafast-secp256k1-backend

Shim API coverage:

secp256k1.h — context, pubkey, seckey
secp256k1_extrakeys.h — keypair, x-only pubkey (BIP-340/341)
secp256k1_schnorrsig.h — Schnorr sign/verify (BIP-340)
secp256k1_ecdh.h — ECDH
secp256k1_recovery.h — ECDSA recovery
secp256k1_ellswift.h — ElligatorSwift (BIP-324)
secp256k1_musig.h — MuSig2 (BIP-327, all 14 functions)
Performance — Bitcoin Core Integration Paths
All numbers from bench_bitcoin (Bitcoin Core's native benchmark harness) on Intel i5-14400F, GCC 14.2.0, Release+LTO, intel_pstate/no_turbo=1, taskset -c 0, nice -20, 5 runs.

Canonical artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json

Transaction signing:

BenchmarkUltralibsecp256k1Delta
SignSchnorrWithMerkleRoot83.9 µs113.4 µs+35% faster
SignSchnorrWithNullMerkleRoot84.0 µs113.0 µs+35% faster
SignTransactionECDSA149.5 µs165.1 µs+10% faster
SignTransactionSchnorr125.4 µs137.5 µs+10% faster
Script verification:

BenchmarkUltralibsecp256k1Delta
VerifyScriptP2TR_KeyPath45.4 µs46.3 µs+2.0% faster
VerifyScriptP2TR_ScriptPath76.5 µs83.8 µs+10% faster
VerifyScriptP2WPKH46.0 µs45.8 µsparity (within noise)
Block validation aggregate (ConnectBlock, 2000 unique signatures):

ScenarioUltralibsecp256k1Delta
All ECDSA254.3 ms257.4 ms+1.2% faster
All Schnorr253.0 ms255.3 ms+0.9% faster
Mixed (2k Schnorr + 1k ECDSA)253.9 ms257.7 ms+1.5% faster
Without LTO: ConnectBlock is ~0.5–1.0% slower than libsecp256k1 due to i-cache pressure from a larger code footprint. LTO is required for Ultra to win the aggregate. This tradeoff is documented in docs/SHIM_KNOWN_DIVERGENCES.md.

Bitcoin Core test suite: 749/749 passing with Ultra backend (GCC 14.2.0, May 2026).

Performance — Constant-Time Signing Primitives
From docs/bench_unified_2026-05-16_gcc14_x86-64.json. CT-vs-CT co-measured in the same run (ratios are TSC-independent):

OperationUltra CTlibsecp256k1Ratio
CT ECDSA sign21.6 µs59.7 µs1.30× faster
CT Schnorr sign (BIP-340)18.1 µs46.5 µs1.28× faster
Schnorr verify84.3 µs84.3 µsequal
Field arithmetic primitives:

PrimitiveUltralibsecp256k1Ratio
field_mul20.1 ns26.5 ns1.32×
field_sqr18.7 ns22.3 ns1.19×
field_inv1253.9 ns1506.0 ns1.20×
field_from_bytes4.8 ns13.0 ns2.71×
Continuous Audit and Assurance (CAAS)
The repository includes a continuous audit infrastructure tracking security regressions across every commit.

Current state at v4.0.0:

262 exploit PoC modules covering 20+ CVE/attack classes — all pass
369 total audit modules (262 exploit PoC + 107 non-exploit)
CAAS autonomy score: 100/100 (8/8 gates)
Source: docs/SECURITY_AUTONOMY_KPI.json

Audit surfaces include: nonce reuse, side-channel timing (dudect), CT boundary verification, batch verify soundness, MuSig2/FROST protocol attacks, adaptor signatures, DER BIP-66 strict parsing, BIP-340/RFC-6979 known-answer tests, Wycheproof vectors, structure-aware fuzzing, differential testing vs libsecp256k1, and Python-based algebraic property testing.

Security properties enforced:

Constant-time signing: ECDSA, Schnorr, MuSig2, FROST, BIP-324 XDH
Per-context DPA blinding (secp256k1_context_randomize fully implemented)
Strict scalar parsing for private key inputs (parse_bytes_strict_nonzero)
Fail-closed batch signing APIs
BIP-66 strict DER enforcement in all shim paths
Benchmarking Methodology
Benchmarks distinguish between:

CT vs CT — constant-time Ultra signing vs constant-time libsecp signing (production-equivalent, fair comparison)
Bitcoin Core integration — bench_bitcoin binary, real validation pipeline
LTO vs no-LTO — both measured and documented
Warm-cache vs cold-cache — noted where applicable
All claimed improvements include error percentage from nanobench's internal statistics. Inconclusive results (overlapping ranges) are reported as such. Results are reproducible from the canonical JSON artifacts in the repository.

Reproducibility
Builds are deterministic:

-ffile-prefix-map strips source paths from debug info
SOURCE_DATE_EPOCH awareness
Fixed -march=x86-64-v3 (no host-native variation)
SLSA provenance attached to v4.0.0 release artifacts (via Sigstore/Cosign)
Platform Coverage
CI passing on all platforms as of v4.0.0:

PlatformArchitectureCompiler
Linuxx86-64-v3GCC 14 / Clang 17
LinuxARM64GCC 14
LinuxRISC-V 64GCC 14
macOSARM64 (Apple Silicon)Clang 15
Windowsx86-64MSVC / GCC
Additional: Android ARM64 (NDK), WASM, ESP32, STM32.

Known Limitations
ConnectBlock improvement requires Release+LTO. Without LTO: ~0.5–1.0% slower than libsecp256k1.
GPU backends (CUDA, OpenCL, Metal) are present but not part of the Bitcoin Core evaluation profile.
This covers the CPU backend only.
Current Objective
No mandatory integration path is proposed. The current objective is to make an alternative backend available for evaluation on technical grounds, with reproducible evidence, minimal integration surface, and an easy rollback path.

The default backend remains libsecp256k1. All existing behavior is preserved unless the new backend is explicitly enabled at build time.

Reviewer Entry Path
git clone https://github.com/shrec/UltrafastSecp256k1
cd UltrafastSecp256k1
python3 ci/verify_external_audit_bundle.py --allow-commit-mismatch
Key documents:

docs/BITCOIN_CORE_BACKEND_EVIDENCE.md — full reviewer package
docs/BENCHMARKS.md — benchmark methodology and raw data
docs/AUDIT_CHANGELOG.md — security audit history
docs/SHIM_KNOWN_DIVERGENCES.md — documented behavioral differences from libsecp256k1
All performance numbers are from controlled benchmark runs with hard turbo lock. Raw data available in the repository. Canonical benchmark artifact: docs/BITCOIN_CORE_BENCH_RESULTS.json, docs/bench_unified_2026-05-16_gcc14_x86-64.json.

UltrafastSecp256k1 v3.67.0

Wed, 22 Apr 2026 09:10:44 +0000

v3.67.0 — CAAS hardening, multi-CI reproducible builds, OpenSSF Scorecard cleanup, Zenodo + funding outreach
This release closes the remaining CAAS gap-closure roadmap, lands the multi-CI reproducible-build attestation surface, brings the OpenSSF Scorecard code-scanning queue to zero open alerts, and pre-stages Zenodo metadata + a funding-outreach playbook. No public-API or ABI breakage; no behavioral changes to the crypto engine.

Highlights
Continuous Audit (CAAS) — roadmap complete
All eleven CAAS hardening items (H-1 … H-11) closed in a single sweep.
Gap-closure roadmap G-1 … G-10 closed: threat model, RNG entropy attestation, hardware side-channel methodology, compliance stance, INTEROP matrix, multi-CI reproducible builds, CT-tool independence, SPEC traceability matrix, protocol spec, traceability-join gate, RFC 9116.
scripts/audit_gate.py now wires G-1 / G-1b / G-8 / G-10 as first-class sub-gates; caas_runner.py is fail-fast across all five stages.
scripts/check_exploit_wiring.py enforces the Exploit / Audit Test Conversion Standard at CAAS Stage 0 — every audit/testexploit*.cpp file must be wired into unified_audit_runner.cpp or the gate refuses the push.
Audit dashboard refreshed: hardening progress 12/12 (100%).
Multi-CI reproducible-build attestation
.gitlab-ci.yml and .woodpecker.yml (Codeberg) added alongside the existing GitHub Actions surface — the same release artifact is now built on three independent CI providers and verified byte-identical via SHA-256.
docs/MULTI_CI_REPRODUCIBLE_BUILD.md documents the protocol; docs/SUPPLY_CHAIN_LOCAL_PARITY.md describes the local-parity check.
INTEROP differential testing
First INTEROP §2 reference wired: OpenSSL 3.x random-vector differential PoC (audit/test_exploit_differential_openssl.cpp), advisory module, host-only.
INTEROP §3 closure tracked for k256 (Rust), btcd (Go), BoringSSL, WolfSSL, NSS, MuSig2 wire, FROST wire.
OpenSSF Scorecard — code-scanning queue cleared
All open code-scanning alerts on main resolved.
PinnedDependenciesID (6): every GitHub Action pinned by 40-character SHA in mutation-weekly.yml, rocm-smoke.yml, and formal-verification.yml; pip installs in those workflows switched to pip install --require-hashes -r ... against new hash-pinned requirement files.
TokenPermissionsID (1 fixed in code): caas-evidence-refresh.yml top-level contents: write dropped to read; write retained only at the job level where the workflow actually pushes refreshed evidence back to dev.
Six remaining TokenPermissionsID alerts dismissed as legitimate job-scoped writes (release sync-docs, audit-report publish to gh-pages, bench-regression baseline push, three ClusterFuzzLite SARIF uploads).
BranchProtectionID resolved at config level: main-protection ruleset hardened — bypass_actors=, required_approving_review_count=2, require_code_owner_review=true, require_last_push_approval=true, dismiss_stale_reviews_on_push=true.
Crypto bug-pattern scanner
13 CVE-grounded pattern checkers added to scripts/dev_bug_scanner.py (timing-dependent branches on secret data, missing zeroization, RFC 6979 misuse patterns, ECDSA nonce reuse signatures, scalar-mod-n omission, …).
False-positive reduction pass across eight checkers; investigation report at docs/SCANNER_INVESTIGATION_REPORT.md.
GPU backend parity
schnorr_snark_witness_batch parity gap closed via deterministic host-side CPU fallback in gpu/src/gpu_backend_fallback.cpp — CUDA, OpenCL, and Metal now all return correct byte-identical results. Native GPU kernels remain a future optimisation; public-data-only operation.
Cross-compile / CI fixes
arm64 + riscv64 cross-compile no longer picks up host OpenSSL headers via bare has_include. The OpenSSL gate is now driven by a CMake UFSECP_HAVE_OPENSSL=1 define that is only set when find_package(OpenSSL) actually links — the source guard requires both the define and has_include.
-Werror build no longer trips on OpenSSL EC_KEY deprecation warnings (pragma block scoped to the differential PoC).
CAAS verdict accepts both PASS and PASS with advisory.
Visibility surface
.zenodo.json added — academic metadata staged for the next release; the next release-tag push will trigger Zenodo archival and DOI minting (Zenodo↔GitHub OAuth toggle is enabled).
README.md "Cite this work" section + DOI badge placeholder.
CITATION.cff linked from "Where to Start"; docs/ADOPTION.md and docs/FUNDING_TARGETS.md linked next to it.
docs/FUNDING_TARGETS.md — funding playbook covering Bitcoin grant programmes (HRF, OpenSats, Brink, Spiral, Strike Catalyst, MIT DCI), Ethereum programmes (EF ESP, Protocol Guild, EF Academic, Optimism RetroPGF, Arbitrum, Coinbase / Base), EU / cross-cutting (NLnet NGI Zero, Sovereign Tech Fund, OSTIF, GitHub Accelerator, a16z crypto Open Source Grants), with 30-second + 5-minute pitches and an evidence-pointer column.
README.md hero block now carries explicit CTAs: a one-line invitation for production users to PR themselves into docs/ADOPTION.md, and a one-line pointer for prospective sponsors to docs/FUNDING_TARGETS.md.
Documentation reconciliation
Exploit-PoC counts reconciled across all audit docs to the real number (189).
Non-exploit module + CI workflow counts reconciled to reality.
docs/SPEC_TRACEABILITY_MATRIX.md paths reconciled; traceability-join gate flipped to strict by default.
Compatibility
C ABI: unchanged.
Public C++ API: unchanged.
GPU backend GpuBackend virtual interface: one method (schnorr_snark_witness_batch) gained a deterministic CPU fallback; previously returned Unsupported on every backend.
Reproducible build: byte-identical to v3.66.0 for the engine + library outputs; only CI / docs / audit-tooling surface changed.
Adoption
Sparrow Wallet Frigate ships UltrafastSecp256k1 by default since 1.4.0. See docs/ADOPTION.md for the integration details and Craig Raw's independent benchmarks.

Cite this work
This release will be archived on Zenodo with a DOI assigned automatically once the tag push completes. See .zenodo.json and CITATION.cff.

https://github.com/shrec/UltrafastSecp256k1/releases/tag/v3.67.0
https://github.com/shrec/UltrafastSecp256k1

Bitcoin Dust Attacks: What They Are and How to Defend Against Them

Fri, 17 Apr 2026 13:07:12 +0000

In the context of blockchain, dust is referred to as tiny amounts of any cryptocurrency that is uneconomical to spend.
An amount is considered uneconomical to spend when the transaction cost it incurs is greater than its value.

An attack is a malicious-intent action that attempts to do things like steal funds, exploit loopholes in rules, or disrupt the network. There are different types of attacks in Bitcoin. One of them is the Dust Attack.

How addresses/keys today in Bitcoin work:

Bitcoin uses Elliptic Curve Cyptography, which is a form of asymmetric cryptography involving a keypair instead of a key, where there is the private key, and there is the public key. Public keys are derived from private keys. They are secured by the discrete-log problem in math, which ensures that it is extremely difficult to work your way back from a public key to a private key. There are different forms of spend, but the basic rule is simple: public keys are associated with bitcoins recorded on the blockchain, and the controller of the keys (the holders of the corresponding private key) can spend the bitcoins, by addressing them to some other public key. Addresses are derived from public keys.
Now, the blockchain is a public network, implying that transactions there are completely visible, so that when a transaction happens, you can see what addresses are involved in the transactions, and the amounts spent.
Bitcoiners love their privacy however, so a natural solution is to control more than one keypair, so that you can send different addresses for different transactions, and make it more difficult for addresses to be traced to you.

Modern wallets have a clever way of doing this whereby from a seed, a private key can be derived, and a whole tree of child keys (private and public) can be derived. The whole idea is that each user has a master key, that gives birth to descriptors, that are used to deterministically derive new keypairs, to evolve into a whole tree of keys, so that any key in the tree can be parent to other keys, and there is no limit on the depth of the tree. More on this can be seen on the Bitcoin Book

What This Implies

This means that for every transaction you receive coins from, you could actually publish a different address, so that the coins could not be traced to you. There is also the concept of internal and external descriptors, where internal descriptors derive wallet addresses you never share - also called change descriptors, because you use them to make change for yourself in transactions. External descriptors derive addresses that are shared, for you to receive coins from other people.
The main point of descriptors and many addresses is privacy through non-reuse. Having these many addresses breaks transaction links, helps hide which output from a transaction is your change (since to the unknowing eye, it is not addressed to your wallet), it limits damages from key leak, so that if a private key gets leaked, just that address and its UTXOs are in danger, not your entire wallet.

Note: As you continue down this article, know that Bitcoin doesn't use the arithmetic balance model, but the UTXO model for amounts, so that you have units of cryptocurrency, instead of a constant you just subtract from when you want to spend. It is like different units of money in a physical wallet. Each unit is called an Unspent Transaction Output (UTXO)

Enter Dust Attacks

In dust attacks, an attacker is not directly after your coins. Instead, they want to uncover your identity, by plotting your identity graph - a map of which Bitcoin addresses belong to the same wallet. This can be used to deanonymize a person, so that you find out their total holdings. Knowledge of who holds how many bitcoins in the past has greatly led to threats, physical attakcs, abuse, torture, etc., so you want to protect yourself.
The knowledge can also be used to link a pseudonymous identity - yours, to a real-world activity.

How Dust Attacks Happen:

Step 1: Target Selection:
First of all, the attacker identifies the address(es) they want to deanonymize. This is done by looking at the blockchain directly, since transactions are public. They could get the address from anywhere at all.

Step 2: Dust Delivery:
Next, the attacker builds the dust delivery transaction. They can do this anyway, but to be economical, it is usually a single transaction, that sends tiny amounts (dust) to all target addresses simultaneously. This amount is chosen so carefully, it is most likely very very tiny, but not so tiny as it wouldn't make sense to spend economically, and above the relay floor, so that even if the victims might not notice it, nodes could relay it.

Step 3: Waiting/Monitoring:
Next, the attacker waits for the wallet owner to spend the outputs they sent. This could be a gamble, depending on how long it takes for the user to spend the coins. If somehow, the victim's wallet's coin selection algorithm picks any of these UTXOs, alongside a real UTXO, it becomes part of the graph.

Step 4: Clustering:
When the user spends this UTXO, the inputs reveal co-ownership, since all inputs to a transaction usually belong to one controller. The attacker now knows that these addresses in the transaction input belong to the target.

Step 5: Graph Expansion:
The attacker can now expand their knowledge graph of you, trace forward or backward, expand the graph, and get closer to whatever goal it is they have.

How To Combat dust attacks:

From the steps above as regards the How of dust attacks, the way to avoid dust attacks is simple: Do not spend the dust. More accurately, do not spend the dust on a canonical transaction. Instead, you can arrange transactions with no output to spend them, so that the entire dust goes into network fees and the trail ends there, or you could mix the dust through a coinjoin with other users' dust. Here it gets mixed with hundreds other dust UTXOs, and the link breaks.

I built a tool using Rust called Hoover that acts to identify dust attack UTXOs, and construct Partially Signed Bitcoin Transactions (PSBTs) that safely spend them to fees, and safely remove them from the users' wallets.

Hoover

Hoover is one of many dust attack tools that have been created for this purpose, and they all have one general idea.
These dust attack tools take in your descriptors, internal and/or external, and register them. Then, on your command, it scans your wallet for dust UTXOs, showing them to you. Promptly, it constructs PSBTs for you to spend these transactions, with OP_RETURN output, so that there is no UTXO output. These PSBTs can then be taken and signed however you may, and broadcasted to the network as regular signed transactions.

One critical part of creating the PSBTs is that you do not create a PSBT that contains dust from multiple addresses. The consolidation must be per address, else it compromises the privacy it aims to protect.

Of course, these steps/processes differ from tool to tool, with different tools making innovations in different parts of the process, such as the nature of the PSBT.
In the same light, the part of the process Hoover does different is in the dust identification.

Usually, the tool would just check all the UTXOs to see which one is below or sometimes equal to the relay floor for that script type. Optionally, a user may configure their minimum number of sats for a UTXO to be considered non-dust, so that for a relay floor of 546 sats, a user may choose to remove every UTXO under 600 sats.
However, a user may by coincidence have a lot of UTXOs that are not economically unspendable, but might be dust attacks, and in this case, depending on how many of them they have, sweeping all from their wallet may be considered waste.
Another case is that depending on how sophisticated the attacker is, the attacker could send as high as 700 sats so that the user is much more likely to spend, and less likely to suspect as a dust attack UTXO, which increase the attacker's chances of succeeding in that attack.
Here is what Hoover does different: Hoover divides dust into different types. UTXOs under the relay floor for a particular script-type are automatically counted as dust, and since they are economically unspendable, they are added to the "psbt staging area".
Hoover goes further to inspect UTXOs as high as a configurable amount by the user, trying to detect dishonest patterns from the source, and marks the UTXO in the list by suspicion level. This results in a user knowing their UTXO may be from a dust attack, even if it is not canonical dust. Some of the flags used to detect these dishonest patterns are:

Dust UTXOs received on a change address: this could be dust, or it could be a bit more than a dust UTXO, but your change addresses should not receive UTXOs from external parties in the first place. A person should only know your change address if they have been monitoring your transactions on the blockchain. This particular flag is highly suspicious.
Multiple of your addresses receiving dust from same txid: this is also almost certainly from a dust attack, and the attacker has actually done their research well and almost accurately, and at this point, doing anything might help finally achieve their goal. The suspicion on this flag is also very high.

Number of outputs of sending tx: this is another fingerprint of a dust attack. The outputs of the sending transaction are inspected. If a high ratio of these outputs are dust, as opposed to not, it is almost certainly a dust attack. The suspicion flag is also high, but not as high as the previous two.
Suspicious round value: in case this wasn't caught by first type of dust, UTXOs with their values too close to, or exactly at the relay floor have to be inspected to be dust attack UTXOs. Other methods are used to check, but the fact that it is too close to the relay floor adds a suspicion weight as well to the UTXO.
Same address sending dust in more than one tx: Catching dust from the same address more than once, even when not in the same transaction is also a bad flag.

There are more flags Hoover uses for detection (some still being implemented), but the idea is the same: In what context did my wallet receive this UTXO? That will tell whether or not the UTXO is a dust-attack UTXO, even for UTXOs above the canonical dust threshold.

Conclusion

When dust attacks succeed, an attacker successfully clusters your address. The attacker now knows you hold significant amounts in bitcoin, and you become a target for extortion; kidnapping or ransom has happened to known Bitcoin holders. For an individual, transaction history exposure could expose salary, spending habits, political donations. Every transaction you ever made/will ever make becomes readable in the context of your identity. Social engineering is also possible with this information in the hands of bad actors. They know when you received large amounts, which services you use, and can do terrible things, such as timely impersonation of such services.

What are some other flags you think would mean UTXOs probably are part of a dust attack campaign?

# CAAS: The Audit System That Caught a Private Key Leak During a Platform Port

Tue, 14 Apr 2026 02:08:19 +0000

I'll start with the bug that makes the case.

I was porting UltrafastSecp256k1 — my secp256k1 cryptographic library — to RISC-V. New architecture, new compiler behavior. The code compiled fine. Tests passed.

But the CT (constant-time) verification pipeline flagged something.

GCC on RISC-V was optimizing my constant-time field arithmetic into branches that depended on secret data. The RISC-V backend had different optimization behavior than x86-64. The result: timing side-channel. The kind that leaks private keys over many observations.

A traditional security audit, done on x86-64, would never have seen this. The audit report would say "constant-time: verified." The library would ship to RISC-V users with a subtle vulnerability.

My CAAS pipeline caught it in the same commit as the port. Fixed. Bug capsule created. Permanent regression test. Can never silently return.

What is CAAS?

Continuous Adversarial Audit System — a methodology for security-critical libraries where every security claim is backed by an executable test that runs on every commit.

The key word is continuous. Not "we audited it in March." On. Every. Commit.

For UltrafastSecp256k1, CAAS consists of:

Three independent CT verification pipelines:

ct-verif.yml — LLVM IR symbolic analysis. Analyzes at compile time whether any secret-bearing operation produces a branch or memory address visible in the IR.
valgrind-ct.yml — Runtime Valgrind taint propagation. Marks secret bytes as undefined at entry, runs the signing path, catches any branch or memory access derived from secret data.
ct-prover.yml — dudect statistical timing. Runs the operation thousands of times with different secret data and tests whether timing distributions are statistically distinguishable.

171 exploit PoC tests covering known CVE and academic attack classes. Each test is a standalone C++ file that actively tries to break the library. All run on every commit. None can be removed.

A bug capsule system:

{
  "id": "BUG-2026-0001",
  "category": "CT",  
  "severity": "critical",
  "title": "CT branch leak in ecdsa_sign_recoverable",
  "fix_commit": "0a93ff4b",
  "exploit_poc": true,
  "expected": { "result": "no_timing_leak" }
}

Run bug_capsule_gen.py and it generates a regression test, an exploit PoC, and CMake integration — automatically. The bug class is permanently sealed in CI.

A domain-specific static analyzer (dev_bug_scanner.py) with 28 rules that generic tools miss:

CT_VIOLATION — fast::scalar_mul() called in signing path (generic tools see valid C++; this is a side-channel)
SECRET_UNERASED — Scalar variable without secure_erase on signing path exit
TAGGED_HASH_BYPASS — sha256() where BIP-340 tagged_hash() is required
RANDOM_IN_SIGNING — non-deterministic RNG in RFC 6979 deterministic signing

~1,000,000+ assertions per build across 55 audit modules covering field arithmetic invariants, scalar operations, point group law, CT properties, and protocol-level correctness.

Full Reproducibility

Everything runs in Docker. Not "runs if you install the right toolchain." Runs with one command:

# Local CI with GitHub parity
docker compose -f docker-compose.ci.yml run --rm pre-push    # 5 min
docker compose -f docker-compose.ci.yml run --rm gh-parity   # full

# Auditor challenge environment
docker build -f Dockerfile.auditor -t ufsecp-auditor .
docker run --rm ufsecp-auditor

# Bit-for-bit reproducible build
docker build -f Dockerfile.reproducible -t uf-repro-check .
docker run --rm uf-repro-check  # compares two independent builds byte-for-byte

The auditor image includes libsecp256k1, @noble/secp256k1, coincurve, and python-ecdsa for differential testing — all hash-pinned. No setup required.

The CI Regression Baseline

The code quality pipeline uses a baseline model:

{
  "dev_bug_scanner": { "HIGH": 0, "MEDIUM": 138, "LOW": 234 },
  "hot_path_alloc_scanner": { "HIGH": 104, "MEDIUM": 44 }
}

CI doesn't require zero findings. It requires findings don't increase. This is mature engineering — existing technical debt acknowledged, new debt blocked. The 104 HIGH hot_path allocations are intentional for performance reasons. If a new commit adds one more HIGH finding, CI fails.

What Happens When You Fork This

You inherit the accumulated security knowledge of every platform port, every bug found, every academic paper evaluated:

RISC-V CT leak → caught → capsule → permanent
Metal field_reduce_512 truncation (affecting ~0.05% of inputs) → caught → capsule → permanent
OpenCL carry propagation bug → caught → capsule → permanent
CT branch leak in ECDSA signing low-s normalization → caught → capsule → permanent

A startup forking this doesn't spend six months building security infrastructure. They start from a system that has already caught the bugs above, with permanent regression tests for each.

Real-World Validation

Craig Raw integrated the library into Frigate for BIP-352 Silent Payments scanning. Real Bitcoin mainnet. Real transactions.

The GPU BIP-352 pipeline achieves 11 million operations per second on an RTX 5060 Ti. Frigate's real-world scan of two years of Bitcoin mainnet history (133M tweaks) completes in 3.2 seconds on 2× RTX 5090s.

What CAAS Doesn't Replace

To be direct:

No third-party audit yet. Documented openly. CAAS is designed to make one cheaper and faster when it happens.
GPU CT verification is code-discipline (branchless source) but not formally pipeline-verified — vendor JIT compilers transform kernels at runtime.
Novel, unknown attack classes have no prior test by definition.

Getting Started

git clone https://github.com/shrec/UltrafastSecp256k1.git
cd UltrafastSecp256k1

# Run the full audit suite locally
docker compose -f docker-compose.ci.yml run --rm pre-push

# Or directly
cmake -S . -B build -DSECP256K1_BUILD_AUDIT=ON && cmake --build build -j
ctest --test-dir build -L exploit -V  # run all exploit PoC tests

CAAS specification: docs/AUDIT_STANDARD.md

The audit infrastructure ships with the library. MIT licensed.

UltrafastSecp256k1 v3.60

Sat, 04 Apr 2026 16:57:36 +0000

v3.60.0 — Audit Campaign Wave II · ZK Layer · Full GPU Parity · Wallet API · Performance

Release date: 2026-04-04
Previous release: v3.50.0 (2026-03-XX)
Commits since v3.50.0: 50+
ABI-compatible with v3.50.x — drop-in upgrade

Security & Correctness

ECDSA large-x fix (cpu/src/ecdsa.cpp) — corrected r_less_than_pmn comparison in both FE52 and 4×64 paths. Wrong PMN constants assumed limb[2]=0; actual p−n has limb[2]=1. Signatures where k·G.x ∈ [n, p−1] (~2⁻¹²⁸ probability per sig) were incorrectly rejected. Equivalent to the Stark Bank CVE-2021-43568..43572 false-negative class. Found and confirmed by Wycheproof tcId 346. ([`ea8cfb3c`])
ECDSA r-overflow test suite (audit/test_exploit_ecdsa_r_overflow.cpp) — 19 checks: k·G.x ≥ n accept case (tcId 346), r=p−3 strict-parse rejection, r=n zero-reduction reject, r=0 reject, range sanity and sign/verify consistency. Closes Wycheproof PR #206 / Stark Bank CVE assurance gap.
Wycheproof ECDSA Bitcoin vectors (audit/test_wycheproof_ecdsa_bitcoin.cpp) — 53 checks: BIP-62 low-S enforcement, tcId 346/347/348/351, high-S malleability boundary, r=0/s=0 special-value rejection, point-at-infinity rejection during verify.
CUDA jacobian_add_mixed_unchecked infinity flag — missing r->infinity = false in the normal code path caused generator table entries table[3..15] to carry uninitialized infinity flags. Scalars with many consecutive high nibbles (e.g. n−1) hit table[15] and produced wrong public keys. All 52/52 CUDA signing tests now pass.
ASan/UBSan clean: 210/210 C++ tests pass under -fsanitize=address,undefined -fno-sanitize-recover=all after full rebuild.

Exploit PoC / Audit Coverage (Wave II)

Suite	Tests	What it proves
`test_exploit_schnorr_nonce_reuse.cpp`	SNR-1..16	Nonce reuse → full privkey recovery via `d' = (s1−s2)·(e1−e2)⁻¹ mod n`; RFC6979 safety
`test_exploit_bip32_child_key_attack.cpp`	CKA-1..18	xpub + child_sk → parent_sk recovery; chained grandchild→child→master; hardened blockage
`test_exploit_frost_identifiable_abort.cpp`	FIA-1..14	`frost_verify_partial()` correctly attributes bad partial sigs; multi-cheater, honest subset
`test_exploit_hash_algo_sig_isolation.cpp`	HAS-1..11	Cross-hash confusion rejected; Schnorr↔ECDSA format confusion; domain prefix isolation
`test_exploit_zk_adversarial.cpp`	14 tests	Malformed/forged ZK proofs: garbage bytes, scalar overflow, identity pubkey, 64-byte-flip
`test_exploit_pedersen_adversarial.cpp`	12 tests	Switch commitment security, imbalanced verify_sum, double-spend detection
`test_exploit_ethereum_differential.cpp`	10 tests	go-ethereum / web3.py / ethers.js KAT vectors, ecrecover, EIP-155/EIP-191, keccak256
`test_fuzz_musig2_frost.cpp`	15 tests	MuSig2 key_agg/nonce_agg/partial_verify; FROST keygen/sign/verify random inputs (5000+ rounds)
`test_wycheproof_ecdsa_bitcoin.cpp`	53 checks	Wycheproof BIP-62 + large-x vectors
`test_exploit_ecdsa_r_overflow.cpp`	19 checks	Wycheproof PR #206 r-overflow class
EIP-712 KAT	12 tests	Typed structured data, 13 assertions

Python Dynamic Audit Suite (9 CTest targets)

All powered by --lib path/to/libufsecp.so, integrated in CI and unified_audit_runner:

CTest target	Checks	What it catches
`py_differential_crossimpl`	1000+	Wrong low-S, pubkey parity bugs, ECDH mismatches (vs coincurve + python-ecdsa)
`py_nonce_bias`	10,000+ ops	Chi-squared + KS + per-bit sweep (Minerva/TPM-FAIL-class biases)
`py_rfc6979_spec`	200+	Independent RFC 6979 §3.2 HMAC-SHA256 nonce derivation + Appendix A.2.5 KAT
`py_bip32_cka`	—	Live BIP-32 parent key recovery demo + hardened immunity
`py_glv_exhaustive`	5000+ scalars	GLV decomposition — adversarial Babai-boundary scalars vs coincurve reference
`py_semantic_props`	1450+	Algebraic properties (kG+lG==(k+l)G), roundtrip, determinism, Hypothesis
`py_invalid_input_grammar`	37	Structured rejection — bad prefix, x≥p, sk=0/n, r=0/s=0, invalid BIP-32 paths
`py_stateful_sequences`	401+	Error-injection recovery, BIP-32 multi-level consistency, 5000-op endurance
`py_dev_bug_scan`	221 files	15-category static scanner: NULL, CPASTE, SIG, RETVAL, MSET, OB1, ZEROIZE, …

ClusterFuzzLite expanded to 5 targets: added fuzz_ecdsa.cpp (sign→verify invariant, wrong-msg, compact parse) and fuzz_schnorr.cpp (BIP-340 sign→verify, adversarial from_bytes).

Performance

Path	Before	After	Delta
CUDA ECDSA Sign (w=8 generator table)	220.9 ns	198.3 ns	−10.2%
CUDA/OpenCL/Metal MSM (GLV Shamir w=1 scatter)	baseline	+18–24%	+18–24%
ARM64 ECDSA Sign (SHA-2 HW accel)	25.89 µs	22.22 µs	−14.2%
ARM64 Schnorr Sign (precomputed)	17.73 µs	16.67 µs	−6.0%
Bulletproof MSM verifier	5,079 µs	2,634 µs	−48% (1.93×)
CPU KPlan zero-alloc (stack wnaf arrays)	heap	stack	alloc eliminated
BIP-352 SHA-256 tag midstate	per-call	precomputed	hash call eliminated
`precompute` (scalar_mul_generator)	2 heap allocs	0	zero-alloc hot path

Zero-Knowledge Proof Layer (new)

Knowledge proofs — non-interactive Schnorr PoK, Fiat-Shamir with tagged SHA-256, no trusted setup.
DLEQ proofs — discrete log equality, batch-verify capable.
Bulletproof range proofs — 64-bit range, MSM-optimized verifier (Pippenger + Montgomery batch inversion).
GPU ZK: CUDA CT kernels (ct_zk.cuh), OpenCL (secp256k1_zk.cl), Metal (kernels 19–22), all batch-capable.
5 new GPU C ABI functions: ufsecp_gpu_zk_knowledge_verify_batch, ufsecp_gpu_zk_dleq_verify_batch, ufsecp_gpu_bulletproof_verify_batch, ufsecp_gpu_bip324_aead_encrypt_batch, ufsecp_gpu_bip324_aead_decrypt_batch.
24 tests in test_zk.cpp; 8.5 benchmarks in bench_unified.

Full GPU Parity (zero Unsupported stubs)

Bulletproof on OpenCL + Metal: removed #if 0 guard in secp256k1_zk.cl; fixed address-space qualifiers; wired bulletproof_verify_batch on both backends. CUDA ↔ OpenCL ↔ Metal parity complete.
4 new OpenCL kernels wired: zk_knowledge_verify_batch, zk_dleq_verify_batch, bip324_aead_encrypt_batch, bip324_aead_decrypt_batch.
4 Metal kernels connected: same 4 operations — kernels existed but dispatch was unwired.
Metal ZK fix: zk_knowledge_verify_batch was treating pubkey buffer as a scalar; corrected to lift_x to recover full point.
CUDA 13 compatibility: replaced deprecated cudaDeviceProp::clockRate / ::memoryClockRate with cudaDeviceGetAttribute. Backward-compatible with CUDA 12. (RTX 5080 / CUDA 13 reported by @craigraw)

Wallet API & Address Formats (new)

Unified Wallet API (wallet.hpp/wallet.cpp) — chain-agnostic key management, address generation, message signing, pubkey recovery — Bitcoin, Ethereum, Tron, and all 28 coins from a single wallet:: namespace.
BIP-39 Mnemonic (bip39.hpp/bip39.cpp) — entropy→mnemonic (12–24 words), validation, PBKDF2-HMAC-SHA512 seed derivation. 57 tests.
Bitcoin message signing (message_signing.hpp) — BIP-137/Electrum compatible: sign, verify, recover, Base64.
P2SH-P2WPKH (nested SegWit, BIP-49) — 3... addresses.
P2SH and P2WSH primitives.
CashAddr (BIP-0185) — bitcoincash:q... addresses.
Tron (TRX) coin — coin_type=195, 0x41 prefix + Keccak-256 + Base58Check. Now 28 coins total.

Bindings

Stable validation closure across 11 language bindings: C#, Java, Swift, Python, Go, Rust, Node.js, PHP, Ruby, Dart, React Native. Fixed wrapper/API drift, zero-length FFI buffer edge cases, Dart NativeFinalizer, local Dart smoke-runner.

Audit Coverage Summary

Surface	Count
C ABI functions (`ufsecp_*`)	155
GPU C ABI functions (`ufsecp_gpu_*`)	23
Unified audit runner modules	70
Python CTest audit targets	9
ClusterFuzz targets	5
Exploit PoC test files	13
Active GPU Unsupported stubs	0

CI/CD

All jobs green on: Linux (GCC + Clang), macOS (arm64 + amd64), Windows, Android (ARM64), RISC-V, ARM64 cross, ROCm, CUDA.
Fixed: macOS externally-managed-environment, Windows Unicode cp1252, Python-order CMake embed, ASan/MSan/TSan py_* symbol issue, SonarCloud coincurve missing.
10 CodeQL code-scanning alerts resolved.

Full diff: v3.50.0...v3.60.0

Don’t Trust, Verify Continuously: UltrafastSecp256k1 Meets Frigate

Wed, 01 Apr 2026 20:35:03 +0000

Introduction

Most cryptographic libraries rely on a simple model:

write code
get audited once
ship a PDF

But modern systems don’t stand still.
They evolve daily.

So I asked a different question:

What if audit was not a document, but a continuous process?

The Idea

UltrafastSecp256k1 was designed around two principles:

High-performance cryptographic execution (CPU + GPU)
Continuous, self-evolving audit system

Instead of relying on one-time audits, the system:

runs ~1M+ checks per audit
performs nightly differential validation
converts every discovered exploit into a permanent test
uses AI-assisted adversarial analysis
enforces correctness through CI

Security is not declared — it is continuously verified.

Real-World Adoption: Frigate

Recently, Sparrow Wallet’s Frigate integrated UltrafastSecp256k1 as its core compute layer.

Frigate is an experimental Silent Payments (BIP352) server that performs high-throughput blockchain scanning using DuckDB.

Instead of treating cryptography as a separate layer, Frigate embeds it directly into the database via a custom extension:

ufsecp.duckdb_extension
ufsecp_scan(...)

This extension is powered by UltrafastSecp256k1.

Performance in Practice

Independent benchmarks from Frigate show:

~40 million operations/sec on 2 RTX 5090

This is not a synthetic benchmark —
it’s a real-world scanning pipeline.

Source:
https://github.com/sparrowwallet/frigate/blob/master/README.md

Why This Matters

This is not about “fastest library” claims.

This is about:

independent integration
real-world validation
reproducible performance
continuous verification

No contracts.
No paid audits.
No marketing.

Just:

clone → build → run → verify

Rethinking Audit

Traditional model:

audit = event
output = PDF
trust = assumption

This model:

audit = process
output = evidence
trust = reproducibility

Final Thought

If a system cannot be verified continuously,
it is only temporarily trusted.

UltrafastSecp256k1 is an attempt to change that.

Bark & Ark: A Deep Dive into Bitcoin's Most Ambitious Payment Layer

Mon, 16 Mar 2026 12:26:35 +0000

A comprehensive technical and philosophical breakdown of what Ark is, how Bark implements it natively on Bitcoin, why it matters, and what could still go wrong.

The Problem Space — Why Bitcoin Needs More Than Lightning
Ark Fundamentals — The Original Design
Bark Specifically — What Second.tech Built and Why
Technical Deep Dive — How It Actually Works
Lightning vs Ark/Bark — Complement, Not Competition
The Bitcoin-Native Philosophy — Why No Liquid, No Bridges, No Soft Fork Required
Risks and Failure Modes — The Honest Breakdown

1. The Problem Space

Bitcoin's Fundamental Scaling Constraint

To understand why Bark was built at all, you first need to understand the ceiling Bitcoin runs into as a payment system. Bitcoin's blockchain can process roughly 3 to 7 transactions per second, a number determined by two hard constraints that were baked into the protocol from the beginning: a block time of approximately 10 minutes, and a block size capped at 1 megabyte.

Contrast that with Visa, which processes around 24,000 transactions per second at peak demand. For Bitcoin to function as a global payment layer used by billions of people, on-chain transactions alone can never get you there. That gap isn't a bug waiting to be patched, it's a fundamental design trade-off that Bitcoin made in exchange for decentralization and security. Bigger blocks mean fewer people can run full nodes, which means more centralization. Bitcoin's community has consistently chosen to preserve that decentralization, which means the base layer will always be a bottleneck at scale.

This is not a failing. It is a deliberate architectural choice. But it does create a genuine engineering problem: if billions of people can't settle transactions on-chain, what do they use instead?

What Lightning Solved — and What It Didn't

The Lightning Network, first described in a 2015 whitepaper by Joseph Poon and Thaddeus Dryja and launched in 2018, was Bitcoin's first serious answer to this question. The core idea is elegant: instead of recording every payment on the blockchain, two parties lock funds into a shared "payment channel" with a single on-chain transaction. They can then make as many payments as they want between themselves off-chain, updating their shared balance instantly and for near-zero cost. When they're done, they close the channel with one more on-chain transaction, and the final balance gets settled.

The genius of Lightning is that it extends this concept to a network. You don't need a direct channel with everyone you want to pay, you just need a connected path through the network. Alice can pay Dave by routing through Bob and Carol, with each hop atomically updating channel balances. In theory, this allows millions of transactions per second with no practical upper bound on throughput.

In practice, Lightning has delivered real results. By mid-2024, Lightning accounted for over 16% of all Bitcoin orders processed by European crypto payments processor CoinGate, up from around 6.5% just two years earlier. Routed payments on Lightning increased 1,212% between 2021 and 2023, according to River's Lightning report. Major integrations, Coinbase adding Lightning support in 2024, widespread wallet adoption across Africa, Latin America, and Asia, have proven that Lightning works and is growing.

But years of real-world deployment have also exposed structural friction points that don't disappear with more engineering. These aren't edge cases, they are fundamental properties of the channel-based model:

The Inbound Liquidity Problem. To receive a Lightning payment, someone else must have already committed bitcoin into a channel pointed toward you. If you're a new user or a new merchant, that liquidity doesn't exist yet. You can't just show up and start receiving. You either have to pay a Lightning Service Provider (LSP) to open a channel toward you, or you have to find someone willing to do it. This is confusing and counterintuitive to new users, and it creates friction during onboarding that has measurably slowed adoption.

Channel Management Complexity. Channels have finite capacity on both sides. If you exhaust the outbound capacity of your channel, you can't send until you receive more. If your inbound side runs dry, you can't receive until you send. Maintaining a "balanced" channel, or managing multiple channels strategically, is a continuous task that requires ongoing attention. For casual users or businesses that don't want to think about this, it's a significant burden. For developers building wallet products, it forces either custodial shortcuts or complex liquidity management code.

Online Requirement and Security Risks. To route Lightning payments, a node needs to be online. This creates a liveness requirement, a technical term meaning the system requires you to be present and active. If a node goes offline and a counterparty broadcasts an outdated channel state (an attempted theft), the victim has a limited time window to detect and respond. While watchtower services mitigate this, they introduce additional trust and complexity. The attack vector is real: in 2023, Lightning developer Antoine Riard disclosed a new class of vulnerabilities called replacement cycling attacks targeting hash time-locked contracts (HTLCs), the cryptographic mechanism Lightning uses to route payments.

Routing Failure Rates. Lightning payments are routed through the network by finding a path with sufficient liquidity at each hop. As networks scale, finding reliable paths becomes harder, particularly for larger payments. Routing failures cause payments to hang, retry, or fail outright. While routing algorithms have improved dramatically, payment reliability remains uneven across the network, especially for large or unusual payment amounts.

The Onboarding Cost Problem. Every new Lightning user needs at least one on-chain transaction to open a channel. During periods of high on-chain fees, like the 2021 and 2023 congestion spikes driven by NFT activity and Ordinals inscriptions, this cost can easily exceed the value of small payments. The channel opening fee makes Lightning economically inaccessible for users who hold small amounts of bitcoin.

These aren't fatal flaws. Lightning is real, it works, and it serves hundreds of millions of dollars worth of payments. But collectively, these constraints define the population of users Lightning can't serve well: new users without existing channels, users in low-trust environments where custodial trade-offs are unacceptable, and users in regions where on-chain fees represent a significant financial barrier to entry.

That gap, self-custodial payments for users who can't or won't manage channels, liquidity, and routing complexity, is exactly the problem Ark was designed to solve.

2. Ark Fundamentals

The Origin Story

In May 2023, a developer named Burak Keceli — known in the Bitcoin community simply as "Burak" — published a proposal to the bitcoin-dev mailing list under the placeholder title "TBDXXX." He had previously been dissatisfied with both Blockstream's Liquid sidechain (which requires a permissioned federation) and the Lightning Network (with its liquidity and privacy constraints). Ark, as the protocol was soon renamed, was his attempt to design a second layer that eliminated those frustrations while remaining fully self-custodial.

Burak's core insight was that Lightning's fundamental limitation isn't the idea of off-chain payments, it's the channel model itself. Channels require pre-allocated, per-user liquidity. They require both parties to be online. They require routing. What if instead, you could take Bitcoin's UTXO model, which is already beautifully simple and doesn't require any of those things, and extend it off-chain?

The Shared UTXO Concept

To understand Ark, you first need to understand what a UTXO is. In Bitcoin, every time you receive a payment, it creates a new "Unspent Transaction Output" (UTXO), essentially a chunk of bitcoin locked to your address that only your private key can spend. When you want to pay someone, you spend that UTXO as an input to a new transaction, and new UTXOs are created as outputs.

Ark's fundamental innovation is the shared UTXO. Instead of each user owning their own separate UTXO on the blockchain, multiple users, potentially hundreds of thousands of them, share a single on-chain UTXO. Each user holds a virtual claim on their portion of that shared pool, represented by what Ark calls a Virtual Transaction Output (VTXO).

From the blockchain's perspective, there is one UTXO. From the users' perspective, they each have their own independently spendable balance.

The elegance of this is immediately apparent from a fee perspective. One on-chain transaction can anchor the funds of a thousand users. The cost of that transaction is split across all of them, making each user's effective on-chain footprint vanishingly small.

What Is a VTXO?

A VTXO (Virtual Transaction Output) is the central unit of value on Ark. The most accurate way to think about it is this: a VTXO is a pre-signed, off-chain transaction that proves you have the right to create a real on-chain UTXO whenever you want to.

You never need to broadcast it. You simply hold it. If everything goes well, if the Ark server keeps operating, if your counterparty doesn't try to cheat, the VTXO stays off-chain forever, and you just keep transacting within Ark. But if anything goes wrong, you can take that pre-signed transaction to the Bitcoin blockchain and claim your sats as a real, fully confirmed UTXO. No one can stop you.

This unilateral exit capability is what makes Ark genuinely self-custodial rather than custodial or federated. You are not trusting the Ark server to hold your money. The server cannot take your money. It can at most inconvenience you by going offline, in which case you exit unilaterally to the base layer.

The VTXO Tree: How Shared UTXOs Are Built

Here's the clever part of the construction. When an Ark server wants to anchor the funds of a large group of users, it doesn't just lock a pile of bitcoin into one massive multi-signature address. That would create a problem: if any user wanted to unilaterally exit, they'd need everyone else to cooperate.

Instead, Ark builds a tree of pre-signed transactions. Think of it like a binary tree. At the root is a single on-chain UTXO — the shared output. This UTXO has a covenant (more on how this works without soft forks later) that says: "the only valid ways to spend this UTXO are the pre-signed transactions we've already prepared." Each internal node of the tree is a pre-signed transaction that splits the previous output into two. Each leaf of the tree is a pre-signed transaction that delivers a specific amount to a specific user.

To exit, a user broadcasts their branch, the chain of pre-signed transactions starting from the shared UTXO down to their leaf. Only their branch goes on-chain. Other users' branches stay off-chain.

The trade-off: an individual exit is more expensive than a direct UTXO spend, because you're broadcasting multiple transactions. But this is far more efficient than having everyone exit simultaneously, which would be catastrophic for blockspace and fees. The tree structure allows individual users to exit independently without forcing everyone else to do the same.

The ASP: Ark Service Provider

Coordinating all of this, building the VTXO trees, batching users together, providing liquidity, managing rounds, is the job of the Ark Service Provider (ASP). The ASP is a server that users connect to in order to participate in Ark. It is always online, provides the liquidity that backs new VTXO issuance, and coordinates the periodic "rounds" that settle the off-chain payment activity into new on-chain transactions.

Critically, the ASP is not a custodian. It cannot steal your bitcoin. Its role is purely coordinative and operational. Users sign their own exit transactions before any of their funds are committed, so the ASP never has unilateral access to user funds. This is architecturally closer to how a Lightning node operates (where you remain in custody of your keys) than how an exchange or custodial wallet operates (where they hold your funds on your behalf).

The ASP does have some power, though: it can refuse to serve you. It can decline to include you in rounds, effectively making you unable to transact within Ark. But it cannot take your money, you can always exit unilaterally.

How Rounds Work

An Ark round is the periodic batch event that anchors off-chain activity to the Bitcoin blockchain. Here's the sequence:

The ASP announces the start of a round.
Users who want to participate: to refresh their VTXOs, make payments, or onboard, communicate to the ASP what they want.
The ASP constructs a new VTXO tree containing all the requested new outputs.
All participating users sign the tree (and their associated "forfeit transactions" — more on this below).
The ASP broadcasts the root transaction on-chain, permanently anchoring this round's state to Bitcoin.

Every round produces a single on-chain transaction. Whether ten users participated or ten thousand, the blockchain sees one output. That is the fundamental efficiency of the model.

The Forfeit Transaction: How Trust Is Maintained

There's a subtle problem in the above flow. When a user is receiving a new VTXO in a round, what stops them from simultaneously trying to broadcast their old VTXO to claim their funds on-chain while also getting the new VTXO? This would be double-spending.

Ark prevents this through forfeit transactions. Before the new VTXO tree is finalized, the user signs a transaction saying "if my old VTXO ever appears on-chain, the ASP gets to claim it." This is the forfeit. The ASP keeps the signed forfeit. If the user misbehaves, by broadcasting their old VTXO after they've already gotten a new one, the ASP can immediately claim the old UTXO as compensation.

The atomicity guarantee works in the other direction too, via connector outputs. The user's forfeit transaction is only valid if the ASP actually published the new round transaction on-chain. If the ASP fails to do so, the forfeit transaction is invalid, and the user loses nothing.

Out-of-Round Payments (ArkOOR)

Rounds are powerful but not instant, users have to wait for the next round to begin, which could be minutes or hours depending on ASP configuration. For cases where speed matters more than maximum trustlessness, Ark supports out-of-round payments, often written as "arkoor."

In an arkoor payment, Alice transfers her VTXO directly to Bob without waiting for a round. She signs a transaction passing her VTXO to Bob. The ASP co-signs to confirm it won't double-spend. Bob receives immediately, nearly instantly, with just one round-trip to the server.

The trade-off: Bob must trust that Alice and the ASP aren't colluding to double-spend. This is a different security model than an in-round payment. If Bob is worried, he can "refresh" his arkoor VTXO in the next round, upgrading it to full trustlessness.

This two-tier system, fast arkoor payments for everyday use, in-round payments for full trustlessness, is one of the most pragmatic design choices in the protocol.

3. Bark Specifically

Who Is Second.tech?

Second is a Belgium-based Bitcoin company whose stated mission is to bring self-custodial Bitcoin payments to billions of people. Their CEO is Steven Roose, a Bitcoin developer with deep roots in the ecosystem. The team decided early on that Ark was the most promising protocol architecture for solving the onboarding and liquidity problems that have held back self-custodial Lightning adoption, and they went all-in on building it.

Bark is the name of Second's implementation of the Ark protocol. It is written in Rust, hosted on GitLab, and designed to be used both as a standalone CLI wallet (for testing and development) and as a library that developers can integrate into their own applications via FFI (Foreign Function Interface) bindings.

The name "Bark" is a playful reference, Ark, plus the sound a dog makes, because why not. Their ASP server implementation is called captaind (the captain of the Ark, presumably).

What Bark Inherits from Ark

Bark is fundamentally an implementation of the Ark protocol design. Everything described in the previous section, VTXOs, VTXO trees, ASPs, rounds, forfeit transactions, connector outputs, arkoor payments, Bark implements all of it. The core protocol design is not Second's invention; it evolved from Burak's original proposal through a community design process.

Bark inherits from Ark:

The shared UTXO model as the primary scaling primitive.
The VTXO abstraction — off-chain ownership claims with on-chain exit guarantees.
The tree-based transaction structure that enables individual exits without group coordination.
The ASP coordination model — centralized coordination with non-custodial guarantees.
The rounds mechanism for periodic on-chain settlement.
The arkoor (out-of-round) payment mechanism for instant off-chain transfers.
The Lightning interoperability design — the ASP acts as a Lightning gateway, enabling users to pay any Lightning invoice directly from their Ark balance.
The unilateral exit guarantee — users can always retrieve their funds on-chain without ASP cooperation.

The Pivotal Decision: Bitcoin-Only, No Soft Fork Required

Here's where Bark diverges significantly from the original Ark vision and from other implementations. The original Ark design, as proposed by Burak, required covenants, a Bitcoin scripting primitive that doesn't currently exist in Bitcoin's protocol.

Specifically, the original Ark needed OP_CHECKTEMPLATEVERIFY (CTV), a proposed opcode defined in BIP 119. CTV would allow a transaction output to specify exactly which future transactions are allowed to spend it, a "covenant" constraining how funds can be moved. With CTV, you could build the VTXO tree natively: the root UTXO's script would encode the entire tree structure, making it deterministic and tamper-proof without requiring any signatures.

The problem: CTV doesn't exist in Bitcoin yet. It's been a contentious proposed soft fork for years. Getting changes into Bitcoin's consensus rules requires persuading the global community of node operators and miners, a process that has historically been slow, contentious, and deeply political. The Bitcoin community does not accept protocol changes lightly, and for good reason.

Second's decision was bold: build Ark on Bitcoin today, without waiting for any consensus changes.

This required solving a fundamental problem. Without CTV, how do you make the VTXO tree tamper-proof? The answer they implemented is called clArk (covenant-less Ark), and it uses pre-signed transactions and multi-party signing to simulate what a covenant would do natively.

The clArk approach: instead of a covenant that mechanically enforces the tree structure, all users who are participating in a given round collectively sign the VTXO tree using n-of-n multi-signature via MuSig2. Because every participant has signed the tree, and any single participant can refuse to sign a conflicting transaction, the tree is effectively locked, not by a covenant, but by collective cryptographic commitment.

This is what Second's documentation describes as a "pseudo-covenant": it achieves the same