Add WojakCoin (WOJAK) support

[reallyshadydev]

Summary

Adds WojakCoin (WOJAK) as a supported chain, following the existing Dogecoin and Pepecoin integration pattern. Single, additive commit — no changes to existing chains.

Changes

• nakamotojs — add wojakcoin / wojakcoinregtest / wojakcointestnet network definitions and a WOJAK case in getNetwork(), plus NETWORKS entries (TS source and compiled src/networks.js + .d.ts).
• node — add chain-setup/WOJAK/{mainnet,testnet,regtest}/ with .env.example and wojakcoin.conf.example.
• Add WojakCoin to the nakamotojs and node package keywords.

Network parameters

Address prefixes, WIF and bip32 versions are taken from wojakcore chainparams:

	mainnet	testnet / regtest
pubKeyHash	0x49 (73, "W")	0x6f
scriptHash	0x05	0xc4
wif	0xc9 (201)	0xef
bip32 pub/priv	0x0488b21e / 0x0488ade4	0x043587cf / 0x04358394

RPC / P2P ports follow wojakcore:

network	RPC	P2P
mainnet	20760	20759
testnet	30760	30759
regtest	30760	18444

Node image

Chain-setup references reallyshadydev/wojakcoin-core:1.12.1, published on Docker Hub. It packages the official WojakCore release binaries (release 1.0.1.2, client version 1.12.1) with SHA256 verification; source: https://github.com/WojakCoinProj/docker-wojakcoin-core

🤖 Generated with Claude Code

[ltardivo]

Thank you for your contribution. We will take a look. For now, I saw that the docker image for WojaCoin project is a placeholder. To be able to run all the integration test, we will need an actual image deployed to DockerHub. If you can continue with your contribution, this is an example for Bitcoin that you can use as inspiration:

• DockerHub project: https://hub.docker.com/r/ruimarinho/bitcoin-core/
• Github repository: https://github.com/ruimarinho/docker-bitcoin-core

[reallyshadydev]

Okay got it! Thanks!

[reallyshadydev]

done lmk if im missing anything thxs!

[ltardivo]

done lmk if im missing anything thxs!

@reallyshadydev thank you for uploading the Docker image.

It would be great if you could provide a multi-platform image instead of an amd64-only build. The examples I linked show how to define a multi-platform image, you can build with docker buildx. This would make it usable on a wider range of systems and architectures.

[reallyshadydev]

Kk I will get that done today thank you so much

[reallyshadydev]

@ltardivo done — the image is now multi-platform (linux/amd64 + linux/arm64), built with docker buildx.

WojakCore only publishes x86_64 release binaries upstream, so I cross-compiled the arm64 (aarch64) wojakcoind/wojakcoin-cli/wojakcoin-tx from the same release commit using WojakCore's own depends system. They're statically linked the same way as the published amd64 binaries (only libc/libstdc++ are dynamic) and are uploaded as *-aarch64 assets on the 1.0.1.2 release. The Dockerfile now selects the right binaries per TARGETARCH and verifies SHA256 for each arch.

Published to Docker Hub under the same tag the tests already use, so nothing changes on your side:

$ docker buildx imagetools inspect reallyshadydev/wojakcoin-core:1.12.1
Name:      docker.io/reallyshadydev/wojakcoin-core:1.12.1
MediaType: application/vnd.oci.image.index.v1+json
Manifests:
  ... Platform: linux/amd64
  ... Platform: linux/arm64

Both variants report the right version (v1.12.1.0), and I verified the arm64 build boots a regtest node, loads BerkeleyDB/chainparams, and computes correct txids (SHA256d) under emulation. Let me know if you'd like any additional architectures.

[reallyshadydev]

Small follow-up: I aligned everything to WojakCore's CLIENT_VERSION (1.12.1.0) so the version numbers are consistent end to end.

• New version-matched release: WojakCoinProj/wojakcore 1.12.1.0 (linux amd64 + arm64, windows, macos)
• Image retagged: reallyshadydev/wojakcoin-core:1.12.1.0 (multi-arch linux/amd64 + linux/arm64)
• Updated BITCOIN_IMAGE in the WOJAK mainnet/testnet/regtest .env.example files to :1.12.1.0

Both arch variants report WojakCore Daemon version v1.12.1.0.

[ltardivo]

@reallyshadydev I can confirm that it is working correctly on my end as well. Thank you!

We are currently in the middle of an important release, but we will continue working on the WOJAK integration as soon as we complete the current work and have resources available. Thank you for your patience.

[reallyshadydev]

You guys are amazing! Thank you!

[ltardivo]

Hi @reallyshadydev (and Wojak team).

First of all, thank you for the excellent work on the WojakCoin integration, we appreciate it.

While testing the integration on regtest we ran into a limitation that we believe is worth addressing. When we try to broadcast Bitcoin Computer transactions, we get this error from the Wojak node:

{"code": -26, "message": "64: bad-txns-too-many-sigops"}

The reason is that WojakCore (based on the 0.12.1.0 codebase) uses the pre-SegWit limits:

Block limit (consensus): 20,000 sigops (MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE / 50)
Per-transaction limit (policy): 4,000 sigops (MAX_TX_SIGOPS = MAX_BLOCK_SIGOPS / 5)

To make metaprotocols like the Bitcoin Computer work on Wojak, you would have to move closer to Bitcoin on both limits. The 4,000 limit is only a policy/standardness rule, not a consensus rule. Raising it does not require a hard fork or even a soft fork. Old nodes will simply remain more restrictive in what they relay. Just increasing the limit per transaction may allow to deploy a few Bitcoin Computer transactions per block. Raising the block limit would allow more chained transactions in a block, which translate to higher throughput and faster applications.

[reallyshadydev]

i will get it done

[reallyshadydev]

check pr lmk

[reallyshadydev]

https://github.com/WojakCoinProj/wojakcore/tree/raise-max-standard-tx-sigops

[ltardivo]

Awesome work @reallyshadydev!

Let me know when you deploy a new docker image. Then we can try it out and post the results here.

[reallyshadydev]

please check my work https://hub.docker.com/repository/docker/reallyshadydev/wojakcoin-core/tags/latest/sha256-6a458568136c0e36eb649ff6925210fd9b29efd0494ba5e6b07d95a223e8b001

[reallyshadydev]

Any news? :D

[ltardivo]

Hi @reallyshadydev, we are preparing a report for this integration, but so far it looks good, our internal integration test are passing completely. I will push the bundles with WojakCoin integrated soon.

[reallyshadydev]

Ah thats amazing new, thank you so much for allowing us to tag along!

[ltardivo]

Hi @reallyshadydev,

We’ve completed the WojakCoin integration and tested it on our side. Here’s what we found:

1. Docker / ARM64 on macOS

When running the multi-platform image on native Apple Silicon (ARM64), the Wojak node fails to start properly.

The logs progress normally up to this point:

2026-08-02 15:06:51 Bitcoin version v1.12.1.0-e54087b-dirty (2026-01-27 06:51:59 +0000)
...
2026-08-02 15:06:51 Using 8 threads for script verification
2026-08-02 15:06:51 scheduler thread start

After “scheduler thread start” no further logs appear and the process never becomes ready. It effectively hangs (and in practice the container keeps restarting).

We suspect the ARM64 build of the latest image is not fully correct.

As a temporary workaround we force the container to run under linux/amd64 emulation, which works reliably:

node:
  image: ${BITCOIN_IMAGE}
  networks:
    - bitcoin
  restart: always
  platform: linux/amd64          # required on Apple Silicon

2. Bytes-per-sigop density rule

You correctly raised MAX_STANDARD_TX_SIGOPS to 16 000. That change is necessary and appreciated.

However we are still seeing rejections when broadcasting Bitcoin Computer transactions. The second, independent check that fires is the bytes-per-sigop density rule. This is an old anti-DoS policy that rejects transactions whose scripts are “sigop-dense”, i.e. a large number of signature operations (especially bare OP_CHECKMULTISIG) packed into a relatively small transaction. Even though the absolute sigop count is well under 16 000, the density condition still fails. Reference in WojakCore.

Bitcoin itself removed the hard rejection of this check in 0.13 and replaced it with a fee-adjustment approach (see the 0.13 release notes).

Fortunately the check can be disabled. We added the following to wojakcoin.conf:

bytespersigop=0

With that flag the transactions are accepted.

Note for network adoption:
bytespersigop is a policy (standardness) setting, not a consensus rule. This means that every node that wants to relay these transactions, and especially every miner that wants to include them in a block, must also set bytespersigop=0. Otherwise the transactions will be rejected from their mempool and will never appear in block templates. We recommend documenting this requirement clearly for Wojak node operators and mining pools.

3. RPC test – generateToAddress vs generate

All our internal library integration, and all the public lib tests pass except the one that explicitly calls the generateToAddress RPC on regtest:

monorepo/packages/lib/test/lib/computer/rpc-call.test.ts

Line 40 in d107537

it('Should call generateToAddress', async () => {

Wojak only exposes the older generate method.

We would prefer to keep the test suite unchanged, but you can easily fix it in your end, changing the test.

4. Application testing status

Please remember to copy the relevant .env.example files and adjust the environment variables before trying the applications.

In our tests the following apps work correctly on Wojak:

• Chat
• NFT (including minting, listing for sale, and buying listed NFTs)
• Explorer
• Wallet

We encountered one limitation with the Chess application:

We use the full open-source Chess.js implementation inside the chess contract. The module is approximately 68 KB, which exceeds the maximum transaction size when using the multisig module type specifier (on Bitcoin and Litecoin we rely on Taproot, which has a tested limit of roughly 400 KB).

To deploy the chess contracts (and therefore run the chess app) the Chess.js module currently needs to be split into several smaller modules, each deployed in its own transaction, and then loaded together. This “module composition” capability is something we already planned to support natively in the Bitcoin Computer library, and we have opened an issue to implement it properly.

For the time being you can implement the split on top of the current library. We have an example in the documentation showing how to combine modules:
https://docs.bitcoincomputer.io/tutorial/#module-system

Next steps on our side

We have already merged the current staging branch into your PR branch. Once one of our developers has reviewed the internal integration code and given an ACK we will be ready to merge the full library support for Wojak.

In the meantime you are welcome to pull the branch, run the tests on your side, and experiment with the demo applications Looking forward to getting this over the finish line.

[reallyshadydev]

will upgrade codebase and fix build ill comment when done

[reallyshadydev]

We will update to 0.21 , will be ready nxt week. Thank you.