Engineering Update: Building a Verifiable Multi-Asset Bounty Settlement Layer
We have reached an important milestone in the MyZubster bounty payment infrastructure: real Bitcoin transactions are now part of the bounty funding flow, and we have successfully executed and recorded a BTC → ETH treasury conversion intended to provide liquidity for multi-asset bounty settlement.
The important part is not simply that crypto moved.
The important part is that every stage is now represented as a separate, auditable state transition.
From funding to settlement
We are designing the payment architecture around a strict separation of concerns:
Funding Input → Confirmed Funds → Treasury Conversion → Bounty Reward → On-Chain Payout
This distinction matters because receiving funds, converting treasury assets, crediting a reward, and paying a contributor are fundamentally different operations.
A treasury conversion must never automatically imply that a contributor has been paid.
Bitcoin funding
As part of the implementation, we executed real Bitcoin transactions and validated the transaction structure before broadcasting.
The flow includes:
- UTXO selection
- explicit destination outputs
- wallet-controlled change outputs
- transaction signing
- broadcast
- transaction ID tracking
- separation between unsigned, signed, and broadcast states
One of the treasury operations sent:
0.000464 BTC
using the Bitcoin transaction:
2ea0bc209a2d5bcfbf520f830f1a39dee0691e47c461afc316e5aeb2e83cdd2d
The transaction also generated a wallet-controlled change output, which was independently verified before broadcast.
BTC → ETH treasury conversion
Part of the available BTC treasury liquidity was subsequently converted into ETH for bounty settlement purposes.
The recorded conversion was:
0.000464 BTC → 0.014355678390291923 ETH
Ethereum mainnet transaction:
0x62b58e69931ef6046d8f68df39c118fe0b1fc7234b88c780d26a8b53fdcddcc6
The ETH transaction was successfully confirmed on Ethereum mainnet.
Our internal representation records the operation as:
purpose: BOUNTY_SETTLEMENT
state: CONVERSION_COMPLETED
verification.status: VERIFIED
This creates a machine-readable link between the source-side BTC operation and the resulting ETH liquidity without treating the conversion itself as a contributor payout.
Introducing TreasuryConversion
To support this architecture, we introduced a dedicated TreasuryConversion model and service.
A conversion record contains independent source and target information, including:
purpose
provider
source.asset
source.amount
source.txId
target.asset
target.network
target.amount
target.txId
state
verification.status
verification.sourceReference
verification.verifiedAt
recordedAt
This gives the settlement layer an explicit record of what happened instead of attempting to infer treasury state from unrelated bounty or ledger records.
Idempotent recording
Financial operations cannot safely depend on "probably only called once."
The conversion recording path therefore implements idempotency.
After recording the BTC → ETH conversion, we intentionally submitted the same operation again.
Instead of creating another conversion, the service returned:
IDEMPOTENT REPLAY — conversion already recorded
and resolved to the same database record.
This property is critical for payment infrastructure because retries can happen at multiple layers: application retries, worker restarts, network failures, webhook redelivery, or operator intervention.
A retry must not become a second financial event.
Database-backed verification
The verified conversion is persisted independently in MongoDB.
For this operation, the system stores:
source.asset = BTC
source.amount = 0.000464
target.asset = ETH
target.network = ethereum-mainnet
target.amount = 0.014355678390291923
state = CONVERSION_COMPLETED
verification.status = VERIFIED
The conversion layer is therefore no longer just a dashboard abstraction. It has a persistent treasury record behind it.
Provider boundary
We also kept the settlement dashboard independent from the persistence implementation.
settlementDashboardService receives treasury conversion information through a conversion provider boundary rather than performing database I/O directly.
Conceptually:
MongoDB → TreasuryConversionService → Conversion Provider → Settlement Dashboard
This gives us several useful properties:
- the dashboard remains deterministic and testable
- persistence concerns stay outside presentation logic
- conversion providers can fail without taking down the complete dashboard
- future settlement providers can be introduced behind the same boundary
- tests can inject preloaded conversion state without requiring MongoDB
Provider failures are represented as an unavailable conversion layer instead of being silently interpreted as a zero balance or successful conversion.
Accounting state is not blockchain state
One of the most important rules introduced by this work is:
CONVERSION_COMPLETED != BOUNTY_PAID
A completed BTC → ETH conversion proves that a treasury conversion occurred.
It does not prove that ETH was subsequently transferred to a bounty contributor.
Likewise, an internal reward ledger entry represents accounting state. It does not automatically represent an external blockchain payment.
For a bounty to be represented as externally paid, the settlement system must have independent evidence of the actual payout transaction.
This separation prevents one of the most dangerous classes of payment-system bugs: deriving financial truth from an unrelated state transition.
Internal rewards remain separate
MYZ remains an internal reward/accounting layer.
BTC and other incoming assets can represent funding inputs.
ETH or other supported assets can represent treasury liquidity and external settlement assets.
These concepts deliberately remain independent:
Funding != Reward
Reward != Conversion
Conversion != Payout
Internal Ledger != Blockchain
The system connects these layers through explicit references rather than collapsing them into a single balance.
Test coverage
The implementation introduced dedicated tests for the treasury conversion service and additional tests around the settlement dashboard conversion-provider boundary.
The relevant suite completed with:
47 tests passed / 47
The tests cover both successful conversion exposure and provider failure behavior.
We also tested idempotency against the actual persistence path rather than relying exclusively on unit-level assumptions.
Shipped
The implementation has now been committed and pushed to the MyZubster repository:
e20fb856
feat: record verified treasury conversions
The next stage is to connect individual bounty settlement records to independently verified payout transactions while preserving the same separation between accounting, treasury operations, and on-chain settlement.
We are not trying to turn MyZubster into an exchange.
The goal is narrower and technically more important: build a bounty settlement architecture capable of handling multiple treasury assets without losing provenance, idempotency, auditability, or the distinction between internal accounting and real blockchain payments.
Funding → Conversion → Verification → Settlement → Payout
Every transition should be explicit.
Every external payment should have independent evidence.
Every retry should be safe.
And no dashboard state should claim that money moved unless we can prove that it did.
