Block Tops (BTOP) - A minable CashToken

These are some ideas for a minable fungible CashToken.

’ not sure if the transaction hash gimmick is actually possible.

Using both functions and bitshift upgrades, mainnet deployment would come after May '26.

Total Introspection (?)

As the name implies, and like bitcoin blocks themselves, a novel trick of this token might be that the transactions calculate their own hash via introspection. Miners will grind for an nft commitment nonce resulting in a transaction hash below a certain number. Once ordered correctly in a block, these mined transactions should always be emitted in the second (third, etc) transaction slot in a block.

The internal hash calculated in the contract and the actual hash in a block may eventually diverge in the future if new capabilities are added to outputs that alter the transaction hash.

HASH256

Part of the larger goal of this project is to develop the technical capacity within the Bitcoin Cash community to mine directly on low-cost SHA256 ASIC hardware. Since transaction hashes are also hash256, CTOR will advertise these transactions at the near the top of every block they are mined in.

Since there is no ready-made software to mine sha256 CashTokens with ASCIs, someone will have to sort that out. There is now a burgeoning ecosystem of single chip benchtop development hardware. Some enterprising individual may figure out how to under volt cheap ASIC boards on the cheapest DC power.

Difficulty Adjustment Algorithm

As a minority hash project, and to facilitate a stable hash rate, an effective DAA has to be selected.

ASERT seems feasible to implement in CashAssembly with bit shifts:

And it seems to preform quite well in practice:

Emission Schedule

Each tokenbase payout will be a fraction of the running balance of a UTXO. Since a constant fraction paid using a recursive function is a simple half-life or exponential decay, we can easily achieve the outcome of Satoshi’s emission schedule without the boom-and-bust of the stepped 210000 block halving cycle.

The same half-life of around 210k blocks will likely the design parameter, unless there is a strong case to go faster or slower.

Free Gas for Miners

Ideally, the covenant would finance the minimum dust sats for miners in advance, so any sha256 miner with minimal hardware may begin mining for tokens without the pesky need to find 800 sats for their output.

Energy Price Oracle

As previously articulated by @bitcoincashautist , a difficulty target is effectively a price oracle for energy, which is a correlate for capital in the wider world.

The “get” for the community, besides another hard commodity token, would be an on-chain energy price oracle. The challenge here is to aggregate the current difficulty into a single NFT that can be used by anyone in the community without interfering with mining activities.

Each use of the oracle NFT, by another contract, would require for all miners to restart with the new oracle utxo as input to their transaction.

Paired with the need to give each successful miner 800 sats with their tokenbase reward, and the disruption that using the oracle price NFT output would cause to miners, perhaps one solution would be to have users of the price oracle pay a substantial fee (4000-8000 sats) to compensate miners for their troubles.

The main price could be copied to a cheaper contract for use by other dapps.

Threading

There can be many token emitting fungible token outputs miners can select to mine from. There can also be many difficulty tracking NFT threads that get aggregated periodically.

For simplicity, it may be best to put everything on one thread, given that everyone setting or using the oracle is paying the cost.

Game Theory

There can still be shenanigans with miners replacing the mempool mined transactions with their own. If miners with substantial hashpower wanted to commit hashpower to that, I’m not sure the community would complain.

A griefer (that just wanted BTOPs to fail) could attempt to race successful miner’s transactions with an oracle spend, or a competing Block Top tokenbase tx. A minimum utxo age (BIP68) could prevent the difficulty NFT from being spend excessively, as a supplement to the cash requirement.

4 Likes

@bitcoincashautist has developed a similar idea to extract an energy oracle from the main block headers.

And he has developed some basic script for ASERT and difficulty parsing in BitAuth. on the BCH 2025 VM


In contrast to the hashrate and price of Bitcoin Cash, which effectively has a 15 year market history, Block Tops would have a clean slate.

If the token were launched in 2026, there would be no fractional exchanges purporting to hold the token. No exchange, outside BCH, would list a price. There would be no synthetic products or cash-settled swaps controlling the price. There would be no exchanges halting operation when their positions became untenable. The price of Block Tops would be much freer to move organically in response to market demands than the forks of bitcoin.

If someone saw the need to control the price of BTOP, it would involve substantial investment in both connecting CashToken markets and hash power.


Likewise on hash power, the fact there is no ready made software to mine the token is a feature. The development of “bluesky” mining software expertise within the Bitcoin Cash ecosystem would be a substantial side-effect of the token that would likely pay dividends for years. This tiny step might ultimately help us down the road.


Although hashing the current block headers would yield a more oracle accurate initially, a clean start might be far more powerful in the long run.

Aside from the balanced economics of financing and maintaining the oracle outlined above, I think just using introspection within a transaction will turn out to be a lot simpler and cheaper. Although it likely depends on the fothieness of the specific contract implementation.

1 Like

Very interesting concept. Would love to see a CPU minable token using Monero’s RandomX algo and being able to merge-mine with Monero.

Something like this would turn many heads toward Bitcoin Cash.

1 Like

To validate results with the “light” mode version of the RandomX VM requires 0.25 GB of ram. Given what we’ve seen done in our VM, I’m not going to say it’s not possible, but it seems like it might be expensive.

We also don’t have a Blake2 op code.

3 Likes

Likely a show stopper for now. Maybe ssomething simpler like scrypt algo.

A merge min-able clone of LTC, if the LTC chain collapses scrypt ASIC’s can just switch over to BCH fully :wink:

2 Likes

This should be launching on August 1st, 2026:

  • Oracle target/difficulty stored on NFT commitment.
  • Oracle will charge 8,000 sats per use
  • NFT commitment: <32-byte difficulty target> <8-byte nonce>
  • Total token supply will be 21e14 no decimals.
  • Token emission schedule targets 1/420,000th per block,
  • Sat emission of 1500 sats per reward
  • Transaction hash must be lower than difficulty target.

Below is a BitAuth template for the latest contract:

Photon BitAuth Template

1 Like

What is the purpose of this, a proof of concept, could you elaborate how it will be mined and used?

1 Like

Based on community feedback, I’m forking this concept into two different tokens and tweeking both.

  • Photons: a CPU minable token that grinds its own transaction hash, with a signed nonce, which will make initial mining biased toward solo CPU participants.

  • PAFAs: (Pafas Are For Asics) an ASIC minable token that uses an 80-byte CashToken commitment to mimic a block header, and uses conventional compact difficulty and the same nonce address.

I can’t speak to the diverse purpose users might have, but both tokens will create two markets. Each contract will have two spending paths, a mining path and an oracle path.

The first market is a conventional mining market where anyone can exchange energy for money. So users with excess electricity may do some work and use the contract to monetize their resources. As part of this activity, they must update the difficulty or the work level they exchanged tokens at. An engineered side effect is that miners can begin mining tokens without any BCH and obtain some sats in the process of token mining. So both contracts will have decentralized PoW faucet on-boarding like the early design of bitcoin.

The second market is for price data. Anyone may use the current mining difficulty in a transaction by spending the baton and referencing the current price. However, using the oracle isn’t free. The last transaction of the NFT baton is an input all active miners will be currently hashing on, so using the oracle will reset all mining activity as if a transaction were found.

To prevent anyone from constantly resetting the baton, a cost of 8000 sats is imposed as a fee for using the oracle. The sats accumulated by the baton are paid as output to token miners.


As for the value of the mined tokens, the distribution mechanics and scarcity is templated on the main chain, but where the main chain creates market super-cycles with abrupt 210k block reward halving, the design of these contracts is for a continuous reward proportional to one 420,000th of the contract token balance. The idea would be to avoid halving events and have a more stable market value.

There will be on-chain limit order markets for both tokens, so people may speculate there to define what the tokens will be worth.

1 Like

I’ve released Pickaxe Miner, an open-source, GPU miner built for mining PHOTON. The goal is to provide a standalone mining application that people can download, run, inspect, benchmark, and contribute to.

Pickaxe is written in Rust and uses native GPU kernels. In my testing, it achieved roughly 57× the estimated hashrate of the reference implementation. Treat this as an approximate comparison rather than a controlled benchmark; results will naturally vary across hardware and configurations.

The first release includes an interactive terminal interface, headless operation, adjustable mining intensity, and automatic job discovery, winner verification, and submission. Prebuilt downloads are available for Windows and Linux x86_64.

GPU backends are included for NVIDIA through CUDA and AMD through HIP. The bundled NVIDIA PTX currently targets sm_120, while the bundled AMD code object targets gfx1036. NVIDIA has been tested live; the AMD path builds successfully, but I’d especially welcome testing across compatible AMD hardware.

The project is released under AGPLv3, and I plan to add SAFA support in the future. Thanks to @2qx for the PHOTON work and reference web implementation.

Source code:

Feedback, code review, benchmark results, hardware testing, and contributions are very welcome.

1 Like

The work with PickAxe and the other miners is really awesome. The progress in hash power over the last two months has been pretty astounding. This is really great for our secp256k1 implementations.

However, there’s a slight problem with the contract. Rather than require users of the oracle pay a fee (to subsidize miner’s dust) the oracle spending path allows anyone to draw down the cash on the baton by up to 8000 sats. This is a simple (+/-) mistake, but one that will make using the current photon contract somewhat difficult for miners to use in the long run.

Someone’s mining software has also discovered that the hash can be a negative number, but it would be tidy to keep them all together at the top of the block.

So for the long term outlook of the project, I think it’d be best to nuke the current token and start from over in the GPU era.

I plan to relaunch a the new token in the first block after 10:28AM GMT on Saturday October 3rd. I’ll publish the corrected photon contract shortly.

EDIT:

SATURDAY October 3rd, 2026 after 10:28 GMT

Not Saturday the 4th.

1 Like

@ABLA @shrec

There is a chipnet deployment of the new Photon contract that I believe should sort out the two issues limiting the old contract.

Mining software might work with little or no modification(?).

The new contract LibAuth template is here

There is a deployed mini-app on the unspent 3 (Vox) chipnet app

The chipnet address is bchtest:rv0ysasak55ps6gtmp478pg382pz4a9vma3pzy2axd6kyrwlvcxg6ayasygal

The initial version of this contract hardcoded the miner’s output locking bytecode to 25 bytes (p2pkh)

Based on feedback from @ABLA, the contract has been updated to allow variable miner locking script lengths.

I’ve tested the new contract with p2s of 15-bytes, as well as p2sh32. It should support locking bytecodes up to 210-bytes in length, while keeping the CTOR gimmick intact.

The new contract (v3.2) LibAuth template is here

There is a deployed mini-app on the Unspent 3 (Vox) chipnet app

The new chipnet address is:

bchtest:rv9tga4xm2cqhgg3rzs3cpu0suw9qc9xdcvpgqmggffqyaedp6qvysm43tgje

1 Like

added new chipnet contract support works fine with same speed

2 Likes