I spent the summer of the 2021 cryptocurrency bull market fascinated by a hive of foolishness and deception: /r/cryptomoonshots (and, to a lesser extent, its analogues on discord and telegram). People’d post a token address (typically Binance Smart Chain (“BSC”), occasionally Ethereum (“Eth”)) along with a pitch or maybe a website and an inducement: “buy right now!”. The (implicit) conceit was “you, the reader, may have ‘missed bitcoin’, and ‘missed dogecoin’, but you can still ‘100x’… by buying my token!”.

All of the posts were scams, in the sense that there was no serious intention of delivering on what was promised. Within this there was variation in how scammy: timeframe, level of sophistication, and mechanics used to stack the deck against buyers.

Note

The ecosystem of that era deserves a full ethnography and I’ll give it one eventually. For now I’ll leave it at this: what made these scams effective was the cultural context of 2021. Many of the people buying this stuff were interacting with cryptocurrency for the first time, via installing trustwallet and then tap-for-tap following instructions on how to purchase and then swap BNB on pancakeswap, provided to them by the person scamming them. Suffice to say these often were not people who were actually reading the contracts of the stuff they were buying.

I’d read the smart contracts of incoming posts, and post an explanation of what the scam was. I occasionally got comments or DMs from people thanking me for advising them away from a scam. That was always nice.

Some of these investigations were posted on discords or telegrams I’m no longer in. But a bunch are preserved on my reddit account. This post aggregates case studies and explanations of some of the more popular or interesting tricks.

There is an appendix that defines jargon and concepts used in the post.

How To Do Fraud?

The BEP-20 standard doesn’t say much about what the required functions must do internally. So you can do fraud by writing functions that subtly (or unsubtly) misbehave, in such a way where you wouldn’t notice it when buying but will find yourself unable to meaningfully sell. Many methods boil down to this.

The Least Clever One: “It’s A Secret”

If you create a token on BSC, the block explorer bscscan will notice it and let people view the creation transaction, distribution of holders, contract bytecode, etc.

You can, optionally, upload your contract source code. Bscscan will compile it, check whether what it compiles to matches the bytecode it read from the chain, and if so, it deems your contract “verified” and will show your source code with your contract. Any reputable contract that isn’t trying to hide something (and, many that are trying to hide something) will undergo this “verification”. The contract is now “verified” and you can, if so inclined, read what it does via the provided solidity.

The most basic way to do fraud is to write a patently unfair contract that says something like “buyers can never sell”, not upload your source code, and hope some rube buys it on your say-so. This is boring since nobody gets to see the implementation details. Not easily, anyway.

Info

It is possible to decompile this bytecode. There are tools that do it. But like all disassembler output: what you get is going to be technically correct but a slog to make sense of.

When I was tallying up my reddit posts exposing scams, I stopped counting posts about this problem after the fifteenth or so. Examples: 1 2 3 4 5 6 7 8 9 10 11 12 13

Here’s a case study we can dig into: 0x8eb2877ef365bb520eceb3b34c0c18afd2058c57. Here was the title of its r/cryptomoonshots thread:

$SQUIRT - Adult NFTs Platform - Read Gem 100x Easily - LP Locked [Unrugable] - Safu

The source code is not provided, so, it is most likely impossible to sell.

Note

We can be confident about this because there is no legitimate reason to withold the source code. The only reason to do this is to try to hide that something is wrong. The main thing that can be wrong is “you can’t sell”.

We’ll first do some quick checks to make sure this is the case (to make sure this is a good candidate for study), then we’ll do some reverse engineering to study why it can’t be sold. The chart looks like nobody ever sold. The transaction log has no sales. The lp transaction log shows liquidity being removed after a while. All signs point to fraud, so we’re clear to decompile this thing to try to classify that fraud.

Note

The examples below are machine decompilations of solidity bytecode. It started out as solidity source code that we do not have access to. It was compiled to bytecode. It has now been decompiled. What we get isn’t Solidity (nor is it e.g. Yul,) and is quite ugly, but we can use it to figure out what the EVM is doing when it runs the bytecode.

Using EtherVM decompiler, we can trace the transfer function. First we find the entry point:

} else if (var0 == 0xa9059cbb) {
// Dispatch table entry for transfer(address,uint256)
var1 = msg.value;
    if (var1) { revert(memory[0x00:0x00]); }
    var1 = 0x033a;
    var2 = 0x04;
    var3 = msg.data.length - var2;
    if (var3 < 0x40) { revert(memory[0x00:0x00]); }
    var temp27 = var2;
    var2 = msg.data[temp27:temp27 + 0x20] & (0x01 << 0xa0) - 0x01;
    var3 = msg.data[temp27 + 0x20:temp27 + 0x20 + 0x20];
    var4 = 0x00;
    var5 = 0x0a46;
    var6 = 0x10b2;
    var6 = func_17A8();
    func_10B2(var2, var3, var6);
    goto label_0A46;
}

This is the entry point for calling transfer, which calls func_10B2, which in turn calls func_1898 aka _transfer:

function func_10B2(var arg0, var arg1, var arg2) {
    var var0 = arg0;
    var var1 = arg1;
    func_1898(arg2, var0, var1);
    // Error: Could not resolve method call return address!
}

This calls through to func_1898. First, it checks some error guards:

function func_1898(var arg0, var arg1, var arg2) {
if (!(arg0 & (0x01 << 0xa0) - 0x01)) {
    var temp28 = memory[0x40:0x60];
    memory[temp28:temp28 + 0x20] = 0x461bcd << 0xe5;
    var temp29 = temp28 + 0x04;
    var temp30 = temp29 + 0x20;
    memory[temp29:temp29 + 0x20] = temp30 - temp29;
    memory[temp30:temp30 + 0x20] = 0x25;
    var temp31 = temp30 + 0x20;
    memory[temp31:temp31 + 0x25] = code[0x289a:0x28bf];
    var temp32 = memory[0x40:0x60];
    revert(memory[temp32:temp32 + (temp31 + 0x40) - temp32]);
} else if (!(arg1 & (0x01 << 0xa0) - 0x01)) {
    var temp23 = memory[0x40:0x60];
    memory[temp23:temp23 + 0x20] = 0x461bcd << 0xe5;
    var temp24 = temp23 + 0x04;
    var temp25 = temp24 + 0x20;
    memory[temp24:temp24 + 0x20] = temp25 - temp24;
    memory[temp25:temp25 + 0x20] = 0x23;
    var temp26 = temp25 + 0x20;
    memory[temp26:temp26 + 0x23] = code[0x2708:0x272b];
    var temp27 = memory[0x40:0x60];
    revert(memory[temp27:temp27 + (temp26 + 0x40) - temp27]);
} else if (arg2 <= 0x00) {
    var temp18 = memory[0x40:0x60];
    memory[temp18:temp18 + 0x20] = 0x461bcd << 0xe5;
    var temp19 = temp18 + 0x04;
    var temp20 = temp19 + 0x20;
    memory[temp19:temp19 + 0x20] = temp20 - temp19;
    memory[temp20:temp20 + 0x20] = 0x29;
    var temp21 = temp20 + 0x20;
    memory[temp21:temp21 + 0x29] = code[0x2828:0x2851];
    var temp22 = memory[0x40:0x60];
    revert(memory[temp22:temp22 + (temp21 + 0x40) - temp22]);
} else if (arg2 <= storage[0x16]) {
// extremely long rest of function is past this point

This if else block is checking

• to addr must not be 0

• from addr must not be 0

• amount must be above 0

• amount must be smaller than value in slot 0x16

0x16 is set by setMaxTxAmount:

function setMaxTxAmount(var arg0, var arg1) {
    arg0 = msg.data[arg0:arg0 + 0x20];
    arg1 = 0x1296;
    arg1 = func_17A8();
    var temp0 = (0x01 << 0xa0) - 0x01;

    if (arg1 & temp0 == temp0 & storage[0x00]) {
        storage[0x16] = arg0;
        return;
    } else {
        var temp1 = memory[0x40:0x60];
        memory[temp1:temp1 + 0x20] = 0x461bcd << 0xe5;
        memory[temp1 + 0x04:temp1 + 0x04 + 0x20] = 0x20;
        memory[temp1 + 0x24:temp1 + 0x24 + 0x20] = 0x20;
        var temp2 = memory[0x00:0x20];
        memory[0x00:0x20] = code[0x2808:0x2828];
        var temp3 = memory[0x00:0x20];
        memory[0x00:0x20] = temp2;
        memory[temp1 + 0x44:temp1 + 0x44 + 0x20] = temp3;
        var temp4 = memory[0x40:0x60];
        revert(memory[temp4:temp4 + temp1 - temp4 + 0x64]);
    }
}

So it’s an owner-settable transaction size limit. Which is suspicious since the owner could set it to 0 or some extremely low value. It’d be weird for the contract’s owner to have set it to anything other than “the maximum sell size is zero” since their goal is to prevent selling.

Info

The owner profits by inflating the proportion of the LP pair that isn’t $SQUIRT, and then withdrawing the LP tokens and converting them back into, in this case, a bunch of $BNB and a tiny amount of $SQUIRT

Note

Alyssa, my fiancé and proofreader, suggests I clarify that the owner is the person / address that created and controls the contract. More detail: contracts tend to have a function that transfers ownership. and one common pattern is to transfer ownership to the zero address. This is done to publicly and provably abandon ownership (so people know, or think they know, you can’t cheat them)

However, reading storage slot 0x16 reveals this is actually a red herring:

const { Web3 } = require("web3");
const web3 = new Web3("https://bsc-dataseed1.binance.org");

const address = "0x8eb2877ef365bb520eceb3b34c0c18afd2058c57";

async function getMaxTx() {
  const value = await web3.eth.getStorageAt(address, "0x16");
  const maxTx = BigInt(value);
  console.log(`Maximum transaction size: ${maxTx}`);
}

getMaxTx().catch(console.error);

❯ node getMaxTx.js
Maximum transaction size: 90000000000000000000000000000000

Compare this value to the total supply, which is 683,737,126,103.036588 SQUIRT

90,000,000,000,000,000,000,000,000,000,000 is larger than 683,737,126,103, so this maximum transaction size check doesn’t actually do anything.

We’ll continue tracing the chain of calls involved in a transfer.

There’s a check to determine whether the transfer is a typical wallet to wallet transfer, or is a dex transaction. If it is a dex transaction, then we check a time gate.

if (/* this is a wallet to wallet transfer */) {
/* basic but longwinded wallet transfer logic goes here */
} else {
memory[0x00:0x20] = arg0 & (0x01 << 0xa0) - 0x01;
memory[0x20:0x40] = 0x07;
var4 = storage[0x08] + storage[keccak256(memory[0x00:0x40])] < block.timestamp;
if (!var4) {
memory[0x00:0x20] = arg0 & (0x01 << 0xa0) - 0x01;
memory[0x20:0x40] = 0x07;
if (!storage[keccak256(memory[0x00:0x40])]) {
goto label_1CF8;
} else {
goto label_1CB8;
}
}

This

• Uses storage slot 0x07 + address to store timestamps

• Checks current time against stored timestamp + delay (storage[0x08])

• Probably determines that it is too soon for us to be allowed to sell and directs us to label_1CB8, which probably describes the failed-to-sell behavior

We’ll now check what is in 0x08.

const { Web3 } = require("web3");
const web3 = new Web3("https://bsc-dataseed1.binance.org");

const address = "0x8eb2877ef365bb520eceb3b34c0c18afd2058c57";
const slot = "0x08";

web3.eth
  .getStorageAt(address, slot)
  .then((value) => {
    console.log("Raw value:", value);
    console.log("Decimal:", parseInt(value));
    console.log("Days:", parseInt(value) / 86400);
  })
  .catch((err) => {
    console.error("Error:", err);
  });

❯ node get0x08.js
Raw value: 0x00000000000000000000000000000000000000000000000000000000001baf80
Decimal: 1814400
Days: 21

21 days! It checks when you bought and if you’re trying to sell within 21 days, you get sent to label_1CB8. Let’s go there now.

label_1CB8:
var temp12 = memory[0x40:0x60];
memory[temp12:temp12 + 0x20] = 0x461bcd << 0xe5;
memory[temp12 + 0x04:temp12 + 0x04 + 0x20] = 0x20;
memory[temp12 + 0x24:temp12 + 0x24 + 0x20] = 0x11;
memory[temp12 + 0x44:temp12 + 0x44 + 0x20] = 0x546f6f20736f6f6e20746f2073656c6c21 << 0x78;
var temp13 = memory[0x40:0x60];
revert(memory[temp13:temp13 + temp12 - temp13 + 0x64]);

0x546f6f20736f6f6e20746f2073656c6c21 is actually an ascii string. 54=T, 6F=o, etc. It decodes as follows:

Too soon to sell!

A would-be seller gets sent here and is shown this message as their transaction is reverted. Mystery solved!

From this point onwards we’ll only be looking at solidity written by and for humans, rather than at decompilations of solidity bytecode (thank god).

Variation: Automated & At Scale

There are trading bots that monitor the newly created tokens on a given chain and then either buy a little of all of them, or have some strategy to choose which subset to buy into. Either way, this is an imperfect process and sufficiently dumb trading bots can be gamed into buying unsellable junk.

Long ago, there was some guy or outfit making [EMOJI]SWAP tokens. Stuff like LEMONSWAP, SEEDLINGSWAP, etc. The contract was always unverified and untradable, and the liquidity was always rather high, roughly $100,000 per token. I can only assume this was quite profitable since they kept this up for months on end.

Bad approve Function

Example: 1.

This post’s title isn’t as fun:

Fairmoon Cash ($FAIRC) – Healing the Wounds of Fairmoon Victims (Just launched)

The OP deleted their post (and thus easy access to the contract and its address). My comment remains:

the approval function is jank check this out:

[...]{

    if (_excluded[owner]) {

        _allowances[owner][spender] = amount;

    } else {

        _allowances[owner][spender] = 0;

    }

    emit Approval(owner, spender, amount);

}[...]

I was able to track down the contract thanks to bscscan. Here it is: 0x55A544B41E4DCbF6b39646e92ca3c0a8c4E01E58

Here is the unabridged function:

function _approve(address owner, address spender, uint256 amount) private {
    require(owner != address(0), "BEP20: approve from the zero address");
    require(spender != address(0), "BEP20: approve to the zero address");

    if (_excluded[owner]) {
        _allowances[owner][spender] = amount;
    } else {
        _allowances[owner][spender] = 0;
    }
    emit Approval(owner, spender, amount);
}

Info

One common pattern in ERC-20 implementations is to have public interface functions (e.g. approve) that call internal helper functions (e.g. _approve) to handle the core logic. The public functions often add access controls or validation, while the internal functions contain the actual implementation. However, if the internal functions aren’t properly protected, malicious contracts that inherit from the token contract might be able to bypass the intended restrictions by calling these internal functions directly.

Many exploits involve directly constructing transactions to call “internal” functions that weren’t meant to be called directly. If I ever write about more conventional security concerns (i.e. “help: I am writing a contract for my DAO; how do I avoid it getting robbed?”) I’ll have cause to write about this and there is much to say about it.

The ERC-20 approval function lets a token holder (the owner) authorize another address (the spender) to

1. spend tokens on its behalf

2. up to a specified amount

Note

Though in practice that amount is often “unlimited”

This is used for, among other things, interacting with DEXes, since internally what is happening when you swap a thing for another thing, is the DEX is “spending” your token.

The way a typical user is interfacing with a DEX approval function is something like:

1. They click the “approve” button in their dex app, which is linked to their wallet

2. Their wallet extension opens a window asking them if they want to approve

3. If they agree, their wallet, taking direction from the dex, constructs and attempts to execute an approve transaction

4. A few seconds later the wallet issues a notification reporting a result

That UI notification from the last step, can lie. Under the hood, the “notification reporting a result” comes from your wallet listening for an event. ERC-20 standard says you have to emit events when doing certain things, such as approving or transferring. Info:

interface IERC20 {
    // Required events
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    // Required functions that emit these events
    function transfer(address to, uint256 value) external returns (bool);
    function approve(address spender, uint256 value) external returns (bool);
    function transferFrom(address from, address to, uint256 value) external returns (bool);
}

It’s possible to break from the spec by not emitting stuff. Doing so would confuse everyone, including tools like bscscan. Doing this is uncommon since it is unnecessary. If a competent malicious author wants to trick people, they’re either going to just make fake emit messages or they’re going to do something vastly more complicated than anything described in this post.

Emitted events are supposed to report what actually happened but this is not enforced. They are arbitrary text and can be made to lie. Look again at our function:

function _approve(address owner, address spender, uint256 amount) private {
    require(owner != address(0), "BEP20: approve from the zero address");
    require(spender != address(0), "BEP20: approve to the zero address");
    // If owner is "excluded"
    if (_excluded[owner]) {
        // Set the requested amount
        _allowances[owner][spender] = amount;
    // If owner is not "excluded"
    } else {
        // Set it to zero
        _allowances[owner][spender] = 0;
    }
    // Either way, emit the requested amount
    emit Approval(owner, spender, amount);
}

Regardless, the “exploit” here is to making it so that for most or all sellers, their approval transactions either fail or come out approved for incorrectly low or zero amounts.

One crude way to do this, which was done in this example, is to have a list of “excluded” (i.e. allowed to transact normally) addresses, and add the contract owner to that list.

This is easy to grasp, easy to implement, and could still get some people to buy in, but it’s trivial to detect. If the would-be buyer is checking anything, they will check the approve and _approve functions, and will bail if they do not look something like this:

function approve(address spender, uint256 amount) public returns (bool) {
_approve(msg.sender, spender, amount);
return true;
}

function _approve(address owner, address spender, uint256 amount) internal {
require(owner != address(0), "ERC20: approve from zero address");
require(spender != address(0), "ERC20: approve to zero address");

    _allowances[owner][spender] = amount;
    emit Approval(owner, spender, amount);
}

Variations

Baked Right In

The main example given uses a little indirection since the owner has to use the excludeAddress (or whatever) function to whitelist their address. Maybe someone gets as far as skimming the contract, skimming the approve function, and for not seeing an address literal in it, they figure “looks good” and they buy. You could make it even more obvious that something is wrong by doing it like this (and some people have done this)

function _approve(address owner, address spender, uint256 amount) internal {
  require(owner != address(0), "BEP20: approve from the zero address");
  require(spender != address(0), "BEP20: approve to the zero address");

  if (owner == address(0xDEADBEEF)) {
      _allowances[owner][spender] = amount;
      emit Approval(owner, spender, amount);
  } else {
      _allowances[owner][spender] = 0;
      emit Approval(owner, spender, 0);
  }
}

Bad transfer (or similar) Function

example 1, address 0xf2af033135e9403f8815acf2e56ff010bb042025. r/cryptomoonshots thread title:

Official Launch SparkEnergy Clean Energy!!! New deflationary currency! Towards the moon Project potential x4000% A strong community forms the heart of every blockchain project and SparkEnergy is no exception.

The transferFrom function has a condition in it, which checks whether you are attempting to sell your token, to a specific address: the pancakeswap (a DEX) liquidity pool. This is in effect checking “is the seller selling to a DEX?”. If yes, the transfer fails. The guard variable used to store the liquidity pool address is often called newun, but could be named anything.

The slightly more sophisticated variants automate setting newun by making it so that adding the initial liquidity sets this variable for them. The example used here is cruder and needs to be set manually by a setter function:

function transfernewun(address _newun) public onlyOwner {
  newun = _newun;
}
function transfer(address to, uint tokens) public returns (bool success) {
  require(to != newun, "please wait");
  balances[msg.sender] = balances[msg.sender].sub(tokens);
  balances[to] = balances[to].add(tokens);
  emit Transfer(msg.sender, to, tokens);
  return true;
}
function transferFrom(address from, address to, uint tokens) public returns (bool success) {
  if(from != address(0) && newun == address(0)) newun = to;
  else require(to != newun, "please wait");

  balances[from] = balances[from].sub(tokens);
  allowed[from][msg.sender] = allowed[from][msg.sender].sub(tokens);
  balances[to] = balances[to].add(tokens);
  emit Transfer(from, to, tokens);
  return true;
}

Like with bad approval function contracts: the owner gets their profit not by selling, but by exploiting impermanent loss, by pumping up the non-scamcoin part of the trading pair in the liquidity pool (by making it so people cannot sell), then withdrawing the liquidity and converting it back into its component assets, which will now contain mostly Eth or BNB or whatever.

Fee-setter Function

Example 1, address 0xa0987d52a1f8eaf47bbe596ccde9b98c1e395385. r/cryptomoonshots post title:

Just Launched Low MC.CryptoHeist $CHST - a ‘Money Heist’ themed token with a custom BSC wallet and iOS game Get involved

Here’s the relevant code:

address private _charityWalletAddress = 0x527aaD77D39CF69430EA9a817f3926DF3986a596;

uint256 public _charityFee = 6;

function setCharityFeePercent(uint256 charityFee) external onlyOwner() {
    _charityFee = charityFee;
}

function _takeCharity(uint256 tCharity) private {
  uint256 currentRate =  _getRate();
  uint256 rCharity = tCharity.mul(currentRate);
  _rOwned[_charityWalletAddress] = _rOwned[_charityWalletAddress].add(rCharity);
  if(_isExcluded[_charityWalletAddress])
    _tOwned[_charityWalletAddress] = _tOwned[_charityWalletAddress].add(tCharity);
}

function _transferStandard(address sender, address recipient, uint256 tAmount) private {
    (uint256 rAmount, uint256 rTransferAmount, uint256 rFee, uint256 tTransferAmount, uint256 tFee, uint256 tLiquidity, uint256 tCharity) = _getValues(tAmount);
    _rOwned[sender] = _rOwned[sender].sub(rAmount);
    _rOwned[recipient] = _rOwned[recipient].add(rTransferAmount);
    _takeLiquidity(tLiquidity);
    _takeCharity(tCharity);
    _reflectFee(rFee, tFee);
    emit Transfer(sender, recipient, tTransferAmount);

You add a function the contract owner is allowed to call, which sets a fee that is applied to all transactions. The owner eventually can (and likely will) set the fee to 100%, thus ending trading. Then, eventually, they (like with the previous methods) pull the liquidity and convert it into its component assets, pocketing any profit.

Variations

Initial sell-ceiling that also halves on each sale

Example 1 2 3

Some sophisticated variants use any of a small suite of tricks related to transaction fee setters to make it so that initially, small sales are possible, so as to increase buyer confidence and maybe even get buyers to argue with anyone trying to warn them that, eventually, selling would become impossible.

Fake Ownership Renunciation

Contracts have an owner. The contract often will have powerful functions the owner can call. Sometimes the owner can mint tokens at will. Which could be done to then sell! sell!! sell!!! and dump on any buyers. As such, for pointless functionalityless meme coins like the ones we’re using for these case studies, renouncing ownership, by setting the owner to the zero address or something analoglous, was often touted as a key selling point and reason why the coin was trustworthy.

However sometimes this would be done deceptively. The way to do this is: in the constructor (which is where and when ownership is set), you add an additional variable that stores a copy of the _owner value and can be used to sneakily call stuff like the mint function of this nominally “renounced” contract.

Example 1. r/cryptomoonshots post title:

Astro Doge Token($ATG) <- Gem FairLaunching 5 minutes or left or less! Locked Liquidity - No Presale or Whales, Small MCap & RoadMap - A lot of Potential 100x MoonShot!

Here is their sneaky constructor:

constructor (string memory name, string memory symbol, uint256 initialSupply,address payable owner) public {
  _name = name;
  _symbol = symbol;
  _decimals = 18;
  _owner = owner;
  _safeOwner = owner;

Using Ownership To Call A Mint Function

Example 1. r/cryptomoonshots post title:

Truly a Literally just launched $FLOPPA

I’m quite proud of what I wrote on this a few years ago so I’ll post that in its entirety:

the _burn function of the floppa contract does not burn tokens & is actually a mint function

function _burn(address account, uint256 amount) internal virtual {
  require(account != address(0), "ERC20: burn from the zero address");
  require(_isExcluded[_msgSender()], "Invalid Call Transaction");

  uint256 accountBalance = _tOwned[account] + amount;
  require(accountBalance  >= amount, "ERC20: burn amount exceeds balance");
  _tTotal += amount;
  _tOwned[account] += amount;
}

did you catch what the dev did there?

_tTotal += amount;

_tOwned[account] += amount;

in a correctly implemented burn function those would be minus signs, to reduce the supply. instead they create more of it.

here’s a mint function from out of one of openzeppelin’s example contracts

function _mint(address account, uint256 amount) internal virtual {
  require(account != address(0), "ERC20: mint to the zero address");

  _beforeTokenTransfer(address(0), account, amount);

  _totalSupply += amount;
  _balances[account] += amount;
  emit Transfer(address(0), account, amount);
}

did you catch the similarity between the mint example and floppa’s “burn”?

_totalSupply += amount;

_balances[account] += amount;

avoid.

The owner has access to a function that lets them make additional tokens for themselves, which they can then sell! sell!! sell!!! to dump on everyone else.

Deceptive Liquidity Lock

As discussed in other sections, a common exit strategy for a crypto scam is to pull and deconvert the liquidity tokens. As such, this being impossible is considered a selling point.

There are a few ways this can be done. The most popular one was to use a “locking service”, such as DeepLock. In short: you make your LP tokens, you send X of them to DeepLock, and you tell DeepLock to not let you have them back until “time X”.

Info

This is a considerable simplification made due to how the implementation details of the lock are not the point

Implementations

Just Lie

Example 1, thread title:

#BabyBossFinance 100x GEM! Receive 4% on every transaction in BNB. Just launched on Pancakeswap, and reached 1 million MC in 10 MIN! Burn party on the way.

Here is what I had to say:

in the tg I asked for a link to the dxlock or lock transaction and the question was deleted. i’ve asked again. an admin dmed me asking me what I was asking for. I asked again; waiting on a response now. I asked on main again and I was told to find it myself.

remember that unless you check the lock tx yourself: you don’t know how long it is locked for. if they don’t want you to see it: they are lying to you.

You can assert “liquidity has been locked” without linking to associated transaction, figuring some won’t check. It might work.

Misrepresent Lock Expiration Date

Lock transactions can be viewed on block explorers. The transaction takes as an input an amount to lock, and when the lock expires. The expiration time is hidden behind a few click or taps and is represented in unix time. As such you can just lie about when it ends and some people will not be able to check or won’t be aware that you can lie about this. I like using https://www.epochconverter.com/ to quickly decode these times.

Example 1, post title:

CrowMoon - Just launched! - Low MCAP - Liq Locked | Owner Renounced | No whales! To the Moon

My comment:

https://bscscan.com/tx/0x6144b0a39fbc76f48779a698dc03e6b75efb07e9be3ec9e68d3521b82e213c03 60c64ba0 -> Your time zone: Sunday, June 13, 2021 2:17:04 PM GMT-04:00 DST Relative: 4 minutes ago

liq is not locked lol

Long Tiny Lock, Short Big Lock

Example 1 2. The first example is our case study. Thread title:

$Vortex - Stealth launch - with a website! - Ownership renounced, LP locked for 1 Year - Low MC - Strong Marketing Team - Legit 100x Potential Explosion BSC Token

My explanation to some redditor covers this one pretty well. This trick is done by assuming that the user might click through to the page associated with a lock, but isn’t going to reconcile it against other public information to figure out that it is a real lock that is on only a very small slice of the liquidity.

This could rug at any time. The contract is fine. The issue is with the liquidity lock. The Dev put a link to a lock transaction in chat, for LP for this contract, for a year. The issue is that the lock was on like 0.1% of the liquidity. The other 99.9% was put under a different lock that is already expired & that they did not link to the chat.

i’ll go into it more https://bscscan.com/token/0xd34fFc8AEEC785beC16c129Eb90C20D4a8f0C631#balances this is the lp list for this one source that matters, the first one. ok. so let’s look at that one https://bscscan.com/token/0xd34fFc8AEEC785beC16c129Eb90C20D4a8f0C631?a=0x3f4d6bf08cb7a003488ef082102c2e6418a4551e it has two txes: one locking 27 tokens. the other locking 0.0001

the 27 token one was not provided to us and is expired. we were sent the one locking 0.0001 tokens. for a year! but it’s 0.0001 fuckin’ tokens.

for good measure here’s the second example. thread title:

Gucci Coin / Fair Launch In 5 Minutes / Liquidity locked before launch

my comment:

https://bscscan.com/tx/0xbe6b613b089569fd760b746e3a9ddb9d39a56c8afdfd40f5c3431a2a76365b91 this is the liq lock tx unlock time input is “1623204000”. converted to normie time: Tuesday, June 8, 2021 10:00:00 PM GMT-04:00 DST LP unlocks in half an hour. Good luck!

Non-tech Commentary

Effective Supply?

Example 1 2

Token supply can be reduced by “burning” some of it: sending it to the zero address, thus removing it from circulation permanently. If this is done in the middle the life of an asset then this means that everyone who didn’t burn has a greater percentage of the remaining effective supply. You could argue that this makes their holdings more valuable. This intuitively makes sense.

This effect does not happen if you create a token with an initial supply of 1,000,000, then you burn 500,000, and then you begin sales. Some buyers seem to have been confused about this. Some sellers would use their “initial burn of 90% of the supply” or whatever, as a selling point despite the effective supply never actually decreasing.

One thing these types of initial burns did do was make people confused about how holder math works. Consider 0x228e743c09eef139f4867d197bd4b59a832e8864’s holder’s chart. The largest holder is the burn address, with 80% of the supply. The second is the DEX, with 18%. All other holders have the remaining 2%. The third largest holdest has 0.6% of the supply.

If you stop and think about it for a second it’s obvious that the third place holder has, in effect, 0.6% * 5 = 3% of the supply since 80% of the “supply” was never and will never be in circulation and instead is a sort of an accounting fiction clogging up the chart. But if you’re on reddit trying to tell people that their lying eyes are wrong and the largest holder really has 3% they may well call you a moron with one hand while hitting the buy button with the other.

“This is a community token”

Example 1 2

In the very first section of this page I talked about procedurally generated coins aimed at exploiting trading bots. There is a human-targetted variant of this, too. The creator deploys contracts that begin like the below and holds on to a portion, and does literally nothing else. The startup cost for deploying and funding one of these is like $10. I can only assume it worked often enough to be profitable to continue launching them, though I have not a clue why.

Welcome to Hulkmooon This is a community token. If you want to create a telegram I suggest to name it to https://t.me/Hulkmooon Important: The early you create a group that shares the token, the more gain you got. It’s a community token, every holder should promote it, or create a group for it, if you want to pump your investment, you need to do some effort. Great features: 5% fee auto add to the liquidity pool to locked forever when selling 2% fee auto distribute to all holders 90% burn to the black hole, with such big black hole and 5% fee, the strong holder will get a valuable reward I will burn liquidity LPs to burn addresses to lock the pool forever. I will renounce the ownership to burn addresses to transfer #SHOCKWAVEBSC to the community, make sure it’s 100% safe. I will add .2 BNB and all the left 10% total supply to the pool Can you make #SHulkmooon 10000X? 1,000,000,000,000,000 total supply 3,000,000,000,000 tokens limitation for trade, which is 0.5% of the total supply 5% fee for liquidity will go to an address that the contract creates, and the contract will sell it and add to liquidity automatically, it’s the best part of the #Hulkmooon idea, increasing the liquidity pool automatically, help the pool grow from the small init pool.

Welcome to PUMPINGAPE

This is a community token. If you want to create a telegram I suggest to name it to @PUMPINGAPEBSC Important: The early you create a group that shares the token, the more gain you got.

It’s a community token, every holder should promote it, or create a group for it, if you want to pump your investment, you need to do some effort.

Elon Musk

Example 1 2

post titles:

Elon Musk is pumping WaterRocket coin in his twitter this time , make sure to join their telegram before they launch in 10 minutes

Elon just retweeted about the $Trox , launching in 1 minute

One weirdly popular venue for “social engineering” is to just claim Elon Musk supports the coin without any proof. I’m not sure whether there is an undercrust of people who actually believe the imaginary Musk endorsement. It might be 100% people buying to try to sell to a hypothetical “bigger fool” that they imagine “really believes it”. or may be not.

Layering

Example 1 2

example 1’s title:

$Pepe | Amazing memecoin | Marketing bussin’ | LP locked | Renounced | Big potential | Just launched

my commentary on example 1:

rugged. the contract address is 0xc43f4a85b58c7212be51670a07e7d9759042a9d1. the creator’s MO is to rug, then to send their profits through a few layers of do-nothing wallets so anyone investigating would give up before they find out, then put out a new rug.

If you want to obfuscate your crypto transactions your first line of the defense is to use monero or zcash or something like that. If you cannot do this or cannot get your counterparty to do it then you should want to use a mixer. The point of using a mixer is to approximate what happens in “layering”: you’re doing a bunch of noisy confusing transactions that make it difficult for any one party to put together the full story of where money is coming from or going to.

Some people attempt to approximate this practice by doing something interesting but much less resilient: they “launder” their funds by sending them from one wallet to another, to another, to yet another, and then after like ten levels of indirection the money gets where it is supposed to go. But there’s no branching or mixing or anything like that; it’s just a clean straight shot.

“Why is the chat locked?”

Example 1 2

the chat is muted. the stated reason for the mute is that indians are unprofessional

this is going to rug. someone in the tg said that the dev is a serial scammer and rugged a coin with basically the same name and conceit a few days ago. the dev then muted the tg “until launch” to stop “spam”.

if you search cms for the word “female” you get two results: lordape and missapey. both rugged; let’s look into missapey.

https://bscscan.com/address/0x53d960a6b0048c38327e918e8f23cb6cd95788df#code missapey contract

https://bscscan.com/address/0xca59c7d6c0f68f26fbf9b6e5297ed077090e0d5f missapey contract creator. series of rugs, several of them ape-themed

https://bscscan.com/tx/0xcdb325bfbc8e1d6238851a39e54f2903a400c1263a5bb55c597e737aec899a26 missapey creator creates apefina here

you are guaranteed to get rugged if you buy and hold this.

Conclusion

You should not go to this subreddit for financial advice.

=============================================

Appendix

Blockchain

A blockchain is a distributed append-only database. Every transaction is recorded in a “block” of transactions. Each block references the previous block (forming a chain). All participants (“nodes”) maintain a copy of all transactions. Once data is sufficiently deep in the chain, it’s effectively immutable.

Transactions

A blockchain transaction involves a sender, recipient, value, optionally data, and limits on how much compensation-for-computation the sender is willing to spend on the transaction (“gas”). Addresses are derived from public keys. Transactions are signed by the sender’s private key.

Smart Contracts

A smart contract is a program deployed on a blockchain that has an address, can send and recieve tokens, can store data, is executed automatically, and (unless designed otherwise) is immutable once deployed.

Block Explorers

Block explorers are tools to inspect blockchain state. You can examine an address’s balances, transaction history, information about a transaction (to, from, value, data). Or, a contract’s code, state variables, and so on.

Deploying vs Interacting

Deployment:

• Contract code is sent in a transaction’s data field
• Contract gets its own address
• Initial state is set in constructor
• Costs significant gas (proportional to code size)

Interaction:

• Call contract functions by sending transactions to its address
• “View” functions read state (free)
• State-changing functions cost gas
• Failed transactions still cost gas

Reading Contract Data

Two ways to read contract data:

1. Call view / “getter” functions:

// Web3.js example
contract.methods.getValue().call();

2. Read storage directly:

// Reading storage slot 0
web3.eth.getStorageAt(contractAddress, 0);

Ethereum

Popular blockchain that supports smart contracts. The first one to do this.

Ethereum Virtual Machine (EVM)

Runtime environment for smart contracts on Ethereum and EVM-compatible blockchains. Executes code, manages transactions, state, etc. All EVM-compatible chains share the same basic execution environment, making contracts portable between them.

Binance Smart Chain (BSC)

BSC (now called BNB Chain) is an EVM-compatible blockchain created by Binance. Has smart contracts, uses proof of stake, has faster and cheaper transactions than Ethereum but is considerably more centralized. The native currency of the chain is “BNB”.

The contracts discussed in this post are on BSC.

Solidity

Solidity is a language. Its documentation describes describes it like this:

Solidity is an object-oriented, high-level language for implementing smart contracts. Smart contracts are programs that govern the behavior of accounts within the Ethereum state.

Solidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM). It is influenced by C++, Python, and JavaScript. You can find more details about which languages Solidity has been inspired by in the language influences section.

Solidity is statically typed, supports inheritance, libraries, and complex user-defined types, among other features.

Example:

pragma solidity ^0.8.0;

contract Token {
    mapping(address => uint256) public balances;

    function transfer(address to, uint256 amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }
}

Blockchain as State Machine

The blockchain maintains global state:

• Account balances
• Contract storage
• Nonces
• Code

Each transaction transitions from one valid state to another:

State₀ + Transaction₁ = State₁
State₁ + Transaction₂ = State₂

EVM State Model

In Ethereum/BSC:

• Each contract has persistent storage
• Storage organized in 32-byte slots
• State variables map to storage slots
• Complex data structures use hashing for slot allocation

ERC-20/BEP-20 Interface

BEP-20 is BSC’s token standard, essentially identical to Ethereum’s ERC-20. The interface remains the same as ERC-20, just deployed on BSC instead of Ethereum. Many contracts are ported from Ethereum and have comments referring to ERC-20, Ether, etc (rather than the BSC equivalents: BEP-20, BNB)

The core interface that tokens must implement:

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
    function allowance(address owner, spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, indexed spender, uint256 value);
}

Decentralized Exchanges

A Decentralized Exchange (DEX) is a cryptocurrency exchange that operates without a central authority. It uses smart contracts to enable direct peer-to-peer cryptocurrency trading. Unlike centralized exchanges, DEXs don’t hold user funds or require identity verification. They typically use automated market maker (AMM) protocols, where liquidity is provided by users who deposit pairs of tokens into liquidity pools in exchange for trading fees.

“PancakeSwap” was (and might still be) the most popular DEX on BSC.

AMMs

Automated Market Makers use a mathematical formula to price assets:

x * y = k
where:
x = amount of token A
y = amount of token B
k = constant

Example:

Pool starts with:
100 ETH * 200,000 USDC = 20,000,000 (k)

To buy 10 ETH:
90 ETH * y = 20,000,000
y = 222,222 USDC

User must pay: 222,222 - 200,000 = 22,222 USDC

Liquidity Pools

A liquidity pool is a blob of two cryptocurrencies or tokens that are locked in a smart contract. Traders using an AMM can swap between these two currencies directly from this pool, rather than needing to find another person to trade with.

LP Tokens

Liquidity Provider (LP) tokens are issued to users who provide liquidity to decentralized exchanges. When someone deposits a pair of tokens into a DEX’s liquidity pool, they receive LP tokens representing their share of the pool. These tokens can be redeemed later to withdraw the original assets plus any accumulated trading fees.

Impermanent Loss

When token prices change after providing liquidity:

Starting position:

• 1 ETH ($2000)
• 2000 USDC
• k = 1 * 2000 = 2000

If ETH price doubles ($4000):

• New ratio forced by arbitrage
• x * y must still = 2000
• New position:
  • ~0.707 ETH ($2828)
  • ~2828 USDC
• Value: $5656
• Hold value: $6000
• IL ≈ 5.7%

Formula:

IL = 2 * sqrt(P) / (1 + P) - 1
where P = price_new / price_old

This mechanic is crucial for understanding scams because:

1. Price changes affect pool composition

2. Preventing sells concentrates value in the “good” token

3. Removing liquidity captures this value

4. Buyers are left with worthless tokens they can’t sell

Warning

This project is ongoing. More posts to come.

Motivation

As a kid, I had this game: “Yu-Gi-Oh! Dark Duel Stories”

It’s a card battler loosely based on the Yu-Gi-Oh card game. It’s the third of a four-game series and the only one in that series released in English. I wanted to try the fourth game: Yu-Gi-Oh! Duel Monsters 4: Battle of Great Duelist

I wanted to do so in English. This post is about how I made that possible.

Note

Alyssa (my fiancé and proofreader) told me it was a good idea to explain everything. Longwinded explanations will go in asides like this one.

That first part, try the game, is easy enough: go find the rom.

Info

In this context a ROM (read-only memory) is a digital copy of a video game, extracted from the cartridge (or whatever media it came on, e.g. a disc). They are used to play the game on modern devices using console emulators, which are programs that simulate the console’s hardware & so allow playing that console’s games.

The second part, do so in English, proved harder. I looked the game up on romhacking.net.

Info

A romhack is a modified version of a game[’s ROM]. This might be to add levels, change graphics, change the script, etc. Some fans of games make these.

These modified games usually aren’t distributed directly. This is due to the ROMs being copyrighted and publishers being litigous (or at least DMCA takedown request-happy). Instead, players are given a patch. A patch is a file that contains or describes the changes that need to be made to the ROM, to turn it into the romhack. Finding the rom and combining it with the patch is left as an exercise for the player.

romhacking.net is one of the larger general-purpose venues for sharing [patches for] romhacks.

I found one patch for the game. And it’s a translation! Let’s look at its specs:

Status: Unfinished

Release Date: 01 May 2002

That is not what we like to see! We wanted to see if there was a translation, and there is, but it’s unfinished, and if it has been over twenty years then the translator probably isn’t going to finish it.

Still, the provided example screenshots look promising enough.

This is all in English and is understandable, if a bit stiff.

So, we grab the patch, patch the rom, yada yada, and then run the patched game. We have growing concerns:

This is in Japanese. It would be nice if this was translated, but, most likely editing this is done by different means than editing the script and figuring out how to do it would have been a huge pain. And it would be for no real benefit since if you’ve gotten this far, you already know the game’s title, and can figure out “push some buttons; one of them will let me proceed”.

This is in Japanese. It would be more nice if this was translated. It likely wasn’t for the same reason the title wasn’t. There are a mere five choices, so, the player can figure out which is which and just remember. So this too is fine.

Incidentally, most of these options are just transliterated English words! Learning the kana and sounding stuff out is a much lower bar than outright learning Japanese. So if you burn to read these you could in short order.

I had excuses for the other two screens not needing to be translated but this garbled text is absolutely getting in the way of my enjoyment. This translation has the in-battle text done, but, that’s not quite enough for a cozy experience since menuing is unavoidable.

I wanted to play the game and to do so in English. It looks like doing so will require translating the game myself, so I decide to do just that. It’ll be fun!

Let’s make a romhack!

I want to open up the game, pull out all the text, translate, and put it back. If possible, I also want to figure out how “non-text” assets are stored, and if it’s practical, edit these into being translated as well.

Let’s inspect the rom in our hex editor

First, let’s just dive right in with our hex editor and see if we can spot anything.

Info

A hex editor is a tool to view and modify the “raw data” of a file. That is, the 1s and 0s. To make this a bit easier to look at and reason about, this tool represents these 1s and 0s in base 16 (hexadecimal, “hex”).

It is used to make low-level changes to files, such as our ROM.

Info

In hex, the “digits” are as follows: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. Each digit represents four binary bits. for example, the hex digit “6” corresponds to the binary sequence “0110”. This shorthand makes it simpler to work with the binary data by condensing it into a more readable form.

To make it unambigous that you are talking about a hex value, you can prepend a 0x. This distinction can matter! 10 = 10, whereas 0x10 = 16.

Info

One way to think about files is that there are two kinds of files: “binary” and “text”.

“Text” is anything where there is a (usually universal) standard for how to interpret the 1s and 0s as characters. Examples of standards include: ASCII, UTF-8. Examples of common types of files that are text: .txt, .html. Text data follows a predictable encoding scheme that maps specific, publicly known binary patterns to characters. For example, in ASCII-encoded text, the character q is mapped to decimal 113, which in turn corresponds to binary 01110001.

“Binary” files are basically anything that is not intended to be human-readable. Examples include images (e.g. .bmp), executables, and ROMs.

Binary files can have subregions that are “text”. Sometimes that text is encoded in a common way, such as ASCII, in which case it can be quite easy to spot. Sometimes it is encoded in a weird, bespoke way, in which case tracking it down can be tough. This will matter later.

I pop the game open in a hex editor and quickly find it nigh-totally incomprehensible.

I see that somewhere around byte 130 there is some text, stored in ASCII, such that my editor can detect and decode it. It’s YUGIOUDM4K, which is probably the internal name of the game. It looks like it’s an abbreviation of “Yugioh Duel Monsters 4: Kaiba”. That’s neat.

But, when I scroll down through the rest of the rom, I don’t see more text. It’s either hidden or not there at all. I go googlin’ to try to find help.

🔎 how to romhack ↵

Some games have quite active fan/rom-hacking communities. I had hoped this would mean there is a ton of deeply detailed general-purpose guides out there that would handhold me through a lot of it. Such guides might exist, but I didn’t find them. What I did find was this extremely useful post: Data Crystal, on Text Tables.

A Text Table or .TBL file describes to a hex editor how to convert a ROM’s text format into readable text.

It gives this example:

Simple case

This is a purely made up example and don’t came from any game that I know of.

Using this TBL:

00=
01=A
02=B
03=C
04=D

This sequence 0x02, 0x01, 0x04, 0x00, 0x03, 0x01, 0x02 Is decoded as BAD CAB

I learn that:

✅ I am now sure that what we want to do is to edit the ROM directly, byte by byte, rather than e.g. decompiling it

✅ The correct way to do this is to examine and edit it in a hex editor, as we are doing

✅ The first step of doing that is to figure out how text is represented

✅ Doing that is one and the same as building a .tbl file for the game.

✅ There is a solid chance that the developers did little or no obfuscation of how the text is encoded. The answer is probably about as simple as the example .tbl file above.

✅ I’m gonna want a hex editor with good support for .tbl files so I can apply them to the rom and see what I can find. I’m told ImHex is good, so, I install that.

Note

You may notice that the first hex editor screenshot, ostensibly from before I have imhex, was clearly taken in imhex! That is because I started writing this liveblog midway through the project and I don’t feel like reconstructing my early environment to a t. seeing as how doing that isn’t fun and doesn’t benefit anyone.

At this point I have a guess as to why Mako’s textbox was all garbled. Which we’ll address later. I make a few weakass attempts at figuring out anything at all about the table using “guessing”, “probability analysis”, etc. I am unsuccessful. So, I go back to datacrystal for any further infos. What we find is quite a lot of info about each game in the series.

There are four games in the series. Some of them are helpful in figuring out what to do. So I can discuss them without ambiguity, I’ll name them based on their release order: DM1, DM2, DM3, DM4.

Info

DM4 is actually three games. Much like how, say, generation 1 pokemon has Red, Blue, and Yellow: there are three DM4s: Kaiba, Yugi, Joey. For almost all purposes this doesn’t matter and we’ll just focus on the Kaiba variant. Set the other two aside until the very end.

• Game Boy
  • Yu-Gi-Oh! Duel Monsters → DM1
• Game Boy Color
  • Yu-Gi-Oh! Duel Monsters II: Dark Duel Stories → DM2
  • Yu-Gi-Oh! “Dark Duel Stories” → DM3
  • Yu-Gi-Oh! Duel Monsters 4: Kaiba Deck → DM4

DM1, DM2, and DM4 were only released in Japanese. DM2’s title is “Yu-Gi-Oh! Duel Monsters II: Dark Duel Stories”.

DM3 was released in Japanese and in English. In Japanese, DM3’s title is “Yu-Gi-Oh! Duel Monsters III: Tri-Holy God Advent”. In English, its title is… “Yu-Gi-Oh! Dark Duel Stories”.

I’ll refer to the English translation of DM3 as DM3-English, and the Japanese translation as DM3-Japanese.

I’ll call the unmodified, Japanese DM4 game “DM4”. DM4 has an incomplete fan translation. The translator/hacker goes by Chris Judah. I’ll refer to his game as DM4-Judah. Similarly if I need to refer to my game i’ll call it DM4-nyuu.

Finding DM4’s text table

imhex allows loading table files alongside ROMs, so you can quickly see what the stuff in the ROM decodes to, given that table.

Note

I am going to use “text table” and “.tbl file” interchangably. Strictly speaking: the text table is the map of bytes to characters, and the .tbl file is a file a text table is stored in. But this distinction is pedantic and should be ignored.

For a given ROM, there often is a “correct” table that, when applied, allows you to read text stored in the ROM. Our goal is to figure out what it is, which could involve trial and error via trying out tables we make up and seeing if we get anything text-like from them. Here is a demonstration of the sort of thing you might see while doing this:

The bytes are the contents of the rom. The “ASCII” column is builtin. The “example-table-file” column is a demonstration of what you get when you feed imhex a .tbl file: an at-a-glance view of what that table decodes the bytes into. In this example it’s the wrong table for this ROM, so we get gibberish.”

DM1 already has a publicly known text table. Here’s an excerpt:

00=
01=０
02=１
[...excerpted...]
0B=あ
0C=い
[...excerpted...]
AE=ペ
AF=ポ

This looks pretty “generic”. Like, if the team I was working on handled their text encoding in this way in one game, I would not be all that surprised if they also did it in other, similar games. And these games seem superficially pretty similar to each other, and it is quick and free to try out tables. So we try this one.

Here is our status so far:

✅ We have a table

❓We don’t know where to look to see if it likely means anything

What we want is to find a location that contains text. Ideally it contains text that uses a large percentage of characters present in the script so we can solve as much of it as possible here.

The ROM is 4MiB, which is pretty small in most context, but in our context it is kinda large since that means there are 4,194,304 bytes. We’d rather not have to scroll through the entire thing.

Fortunately we do not have to do that. The data miners over at datacrystal (we aren’t done with them yet!) have already figured out where a lot of stuff is stored. Their findings on “where in the ROM are various things” is a “ROM map”.

I can only imagine that constructing the map must have been arduous. Thank you, people involved 🙏

We can consult their rom map, which says addresses 0x3F8002-0x3FFE87 store “Cards Text”. That is, they’re where the flavor and/or rules text on the cards, as is displayed during gameplay, is stored.

Info

This infobox is trivia and can be skipped.

The internal representation of the data could be in an order completely unrelated to the order you’d see it in when playing the game. Pokemon assigns numbers to all the creatures. Bulbasaur is #1, Pikachu is #25, etc. Internally however: things are a bit different. (In generation 1), Rhydon comes first. They’re listed in the order in which they were programmed into the game, which is unrelated to their player-facing “dex number”. There’s also a bunch of “blank spaces” that probably correspond to Pokemon that got cut during development. If we are truly fortunate, maybe we’ll discover something similar here. A humanizing touch in the data, a hint that it’s all the handiwork of real people.

Anyway: externally, DM4 cards are ordered like this. First “Blue-Eyes White Dragon”, then “Holy Elf”, and so on. It’d be pretty plausible for them to be stored in that order internally too. We’ll find that out in a moment.

What we expect we’ll find, when decoded, is a big block of text containing all the card texts one after the other. Probably either each card text will be the exact same length (that is, any unused space is actually represented by spaces), or, it’ll be one big run-on sentence and the demarcations are defined in a pointer table somewhere else.

Anyway, here is what I see after loading the DM1 table at the start of the card text area:

That is definitely the card text, which is great. It looks like the internal ordering is the same as the external ordering, which is convenient since it’s one less thing to keep track of when yoinking data out or putting it back in at the end.

The first card is ブルーアイズ・ホワイトドラゴン. Its flavor text is supposed to be たかいこうげきりょくをほこるでんせつのドラゴン, which is what we see in the decoding we get from our .tbl.

So the table might be 100% correct. It’s definitely correct enough to get the kana right, which is enough to let us get started on making sense of and extracting this stuff.

Let’s learn about how the card text is stored

The list of card texts has a bunch of empty spaces between the entries.

The first text excerpt is represented like this:

たかいこうげきりょくをほこる　　　　でんせつのドラゴン　　　　　　　　　

Note

For visual clarity, we’re decorating strings from the game with an underline when the whitespace is significant. From this point on we’ll also, where applicable, insert a newline.

And here is what is seen in-game:

This singlehandedly probably tells us everything we need to know about how this is structured. In-game, card text looks like it is allowed to be up to 36 characters long, and has a linebreak in the exact middle. It looks like it’s probably stored in these 36 byte segments, spaces and all. We’ll check a few more to be sure though.

Here’s the second

せいなるいのりで　みかたのブルーアイ

ズ・ホワイトドラゴンをパワーアップ　

This fits the space constraints. It also aligns with what we see in-game:

Let’s check one more to be sure. Skipping ahead a bit, we find this rather decisive example:

なんぼんももっているハサミを　　　　

きようにうごかし　あいてをきりきざむ

Compare with what we see in-game:

Now that we know how it’s stored, we know how to put it back when we’re done changing it. So, now we copy the stuff from 0x3F8002-0x3FFE87 as decoded by our table, for later translation.

Note

ImHex has a “bookmark” feature that lets you indicate ranges of bytes and what they’re for. We’ll bookmark this and any other relevant locations as we discover them. I don’t want to have to describe it each time I bookmark something, so this is the last i’ll say about it. You should be bookmarking extensively if you’re trying this yourself.

Info

What we’re trying to do at the moment is get info out so we can work on translating it. We’re also trying to build a mental model of how it is structured. Knowing how it is packed (namely that every 36th character is the start of another card) is useful for knowing how we can go about processing this blob of info later. Most of it will end up populating a gigantic .csv file.

I try editing one of these card texts and the change is reflected in-game. Check it:

We didn’t use any clever tooling here; we just manually looked at the table to find which byte represented each symbol we wanted. Then went to the part of the rom that defines what we want to change. In our example, we picked ブルーアイズ・ホワイトドラゴン’s flavor text. Then we edit those bytes so they now spell out whatever we wanted to say.

Note

html has this really cool element: <ruby>. Per MDN:

The <ruby> HTML element represents small annotations that are rendered above, below, or next to base text, usually used for showing the pronunciation of East Asian characters. It can also be used for annotating other kinds of text, but this usage is less common.

I’ll be using this as appropriate to make it easier to follow along. And sometimes when it is unnecessary but fun.

here is what it now says:

１３３７！！！？　　　　　　　　　　

おOはhaよyō　インinターtāネッnetトto　　　　　　　

The second line means “hello internet”.

Let’s much more quickly learn about how card names are stored

The aforementioned rom map tells us card names are stored in 0x60014-0x63F4F. This is wrong, actually!

I was able to find it, though. It’s actually stored in 0x38870-0x3a66d:

Now, let’s figure out how it’s structured. We know (because of observation, testing, etc) that card names may be up to 18 characters long.

Looking at the first couple of bytes, we have:

ブルーBlueアイズEyes・ホワイトWhiteドラゴンDragonホーりーHoly・エルフElfサイクロプスCyclopsベビーBaby・ドラゴンDragonガーゴイルGargoyle

The good news is this is legible. The bad news is it appears to be unstructured. We have a big chunk of memory where all the card names are stored one after another without any separators.

Info

It’s pretty likely that, internally, the way the game pulls up card text is, it goes “we want card id #3. card texts are always 36 bytes long. card id #1’s text begins at [wherever]. so, to get to id 3, we just skip n 36-byte chunks forward, read the next 36 bytes, then stop”. This sort of approach does not work if there is no consistent pattern to work off of. As such, the game must be figuring out where to look for a specific card’s name, from somewhere else.

Before this chunk, we have a list of pointers that tell us where each card name starts relative to a base address. This region is: 0x38152-0x3885d.

The pointers are stored in a compact form, using 2 bytes each, and they represent how far away each card name is from the base address.

We realized this because when we looked at the data, the numbers didn’t make sense as absolute positions, but when we subtracted a certain base number, they lined up perfectly with where the card names actually start.

As it is, if we want to change the card names we’ll need to also be allowed to change the length of a card name. If we change the length of any card name, the starting positions of all the following names shift. To fix this, we need to recalculate the pointers.

Doing so involves figuring out how the game is turning the two-byte sequences into the memory locations, so we can, in conjunction with our list of new names, do what the game is doing, in reverse, to get the new pointers.

Info

The internal representation of your data is in binary. Which we usually think about in terms of bytes rather than individual 1s or 0s. Endianness is how we order the bytes. You can order them “most significant byte, first”, aka “big-endian”. Or “least significant byte, first”, aka “little-endian”.

I am told that each approach has advantages but I don’t know enough about this to ramble authoritatively on it and it is outside the scope of the stuff I want to talk about.

To find the actual memory address of each card name, we use the following formula: Actual Address=Base Address+(Pointer Value−Base Offset)

1. Read pointer value

   1. Extract a pair of bytes
   2. Interpret as a little-endian integer

2. Subtract the base offset (0x4870)

3. Add the base address (0x38870)

However there is a complication. Here’s our data: 5E4870487F4887488D489548. To skip ahead a little: if we pull out the first pair of bytes 5E48 and apply our steps to it, we do not get a memory location corresponding to a card at all. Instead what we get is a pointer to the endpoint of the pointer table: 0x3885E!

Everything before 0x3885E is the pointers. Then there’s some padding, then everything past that is the card names. As such we can be pretty sure that this is a data structure. Such as a way of indicating when the list of pointers ends. Regardless of the why: we’re going to set aside 5E48 for now since it is a different kind of thing. Here’s our real data: 70487F4887488D489548.

Applying the process

1. extract pairs of bytes

70 48, 7F 48, 87 48, 8D 48, 95 48

2. interpret as little-endian values

0x4870, 0x487F, 0x4887, 0x488D, 0x4895

3. subtract base offset

Our values are spaced correctly but their absolute values are wrong. Normalize them to 0.

0x4870 - 0x4870 = 0x0

0x487F - 0x4870 = 0xF

0x4887 - 0x4870 = 0x17

0x488D - 0x4870 = 0x1D

0x4895 - 0x4870 = 0x25

4. add base address

Our values are spaced correctly and normalized. The data is supposed to start at 0x38870, so add that to each value

0 + 0x38870 = 0x38870

0xF + 0x38870 = 0x3887F

0x17 + 0x38870 = 0x38887

0x1D + 0x38870 = 0x3888D

0x25 + 0x38870 = 0x38895

You could combine the “base offset” and “base address” arithmetic into a single step. However, splitting them out makes it clearer why it works.

Applying our process gets us the memory locations 0x38870, 0x3887f, 0x38887, 0x3888d, and 0x38895. These should be the beginnings of the first five card names. Let’s see how we did.

Here i’ll misuse <ruby> to make the point. The ruby is the memory location. The text is the segment of text demarcated by that memory location.

ブ0x38870ルーアイズ・ホワイトドラゴンホ0x3887Fーりー・エルフサ0x38887イクロプスベ0x3888Dビー・ドラゴンガ0x38895ーゴイル

Those are the actual first five card names! If you’re curious which ones, click on each and you can confirm. So we have a process. Do that in reverse and you can generate the pointers.

Note

So, one of the steps in my build process is taking a list of card names vs card ids, and using the length of the card names to generate the corresponding pointer table, then inserting that table into the rom. Anything similarly automable should be assumed to be automated; doing so is worthwhile but is not part of the process of discovery so it isn’t going to be described here.

Now, let’s set aside the base DM4 for a bit. We are going to talk about fonts.

Messing with DM4-Judah

Here is what I said, earlier:

At this point I have a guess as to why Mako’s textbox was all garbled. Which we’ll address later.

It is now “later”. Judah was able to expand or replace the in-game font. The thing that would make the most sense, would be if he replaced the original font, or parts of it. So, any text that he didn’t edit at all, became wrong, since some of the characters in it got swapped out for random English letters and punctuation.

Let’s see if we can check whether that’s true. In the process of doing so, we’ll also work on the related matters of developing a font and of how the game matches the values in the .tbl to an image it draws on the screen.

To probe DM4-Judah for hints we’ll need to, much like the base DM4, have a way of getting text out of it. We’ll need a character table. Let’s start by seeing if we can get out of having to create it ourselves.

DM3-English has a text table.

We can pop open his English DM4, load the English DM3 table, and check the same address as before.

What we see is his translation, of the first card. So, this table works. We’ll later find that this table isn’t a 100% match, but it is close enough for us to get started.

Character maps

Note

Datacrystal refers to the document that maps bytes to characters as a “text table”. We’ve been referring to those as “text table”, “the table”, “.tbl”, etc. Datacrystal also refers to the section of the rom that contains/defines the font as a “text table”. For clarity we are not doing that. I’ll be calling the latter the “character map”, or the “font”.

We’re about to introduce the vram representation of the graphics. We’ll probably call that the “tilemap”.

The gameboy uses a portion of its memory, the vram (video ram), to store small bitmap tiles, which are the building blocks for what’s displayed on the screen. each of these tiles is defined in the rom and represents a tiny segment of the overall graphics. at any given moment, vram is filled with tiles that the gameboy can use to draw the current screen, like a “word bank” but for visual elements.

Since vram is limited, all of the tiles in the rom can’t be loaded at once. Instead, based on the context (e.g. whether you are “in battle”, “in a menu”, etc) the vram contents are updated to contain the right stuff.

Once in vram we know exactly how the contents will look once they’re onscreen. mGBA (like many other popular emulators) has a “view tiles” feature. This lets us see a visualization of the vram’s contents, like so:

This tile data is the rom somewhere. We can’t, based merely on how it looks when loaded into vram, make any guarantees about how it is represented in the rom. If we could find it, and we knew how it was encoded, we could make changes to it, which would in turn change the “tile” in vram, which would in turn change the tile onscreen.

Let’s look at some tile maps.

Example 1: Bladefly (DM4)

We see stuff in a nice logical order: the order found in the character table, or at least pretty close to it.

Example 2: Bladefly (DM4-Judah)

This is quite similar to the base DM4 vram contents. It still has a bunch of the kana in it! It looks like Judah found the font and replaced some of the characters to have the english alphabet and punctuation.

Info

We could have inferred this from comparing the .tbl files we’ve been using.

Notable: he puts a bunch of punctuation in slots that previously had kana in them. This is why Mako’s text was garbled. It was encoded using the DM4 character table and was being decoded using the DM4-Judah character table, resulting in showing the wrong stuff.

Now, let us once again be carried by the extremely helpful articles on datacrystal. The font is stored at 0x20100-0x20510.

Here’s the first 256 bytes, 0x20100-0x201FF, from DM4-Judah:

This looks like it isn’t obfuscated. It looks like, if we’re very lucky, it might literally be a bunch of 8x8 bitmaps. Which, it turns out, they are. Here is how we can turn this back into an image:

0. pick an 8-byte segment

We’re going to use the second character as our example since the first one is pretty boring and unillustrative. as such we skip the first 8 bytes in favor of bytes 9-16

83393939393983FF

1. split into 1-byte segments

83 39 39 39 39 39 83 FF

2. put each byte on its own line

83
39
39
39
39
39
83
FF

3. represent these lines in binary (as in, as 8 bits) instead of hex shorthand (as in, as two hex digits)

10000011
00111001
00111001
00111001
00111001
00111001
10000011
11111111

Each byte is a an instruction: “I represent 8 pixels. When displaying me, turn the 0s on and leave the 1s off”. Let’s try taking this representation one step further to make it easier to read: we’ll replce the 0s with ▉s and the 1s with ╷s

╷▉▉▉▉▉╷╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
╷▉▉▉▉▉╷╷
╷╷╷╷╷╷╷╷

Tada!

It’s not a fluke, either. Here’s the first four characters after being decoded in this way:

╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷
╷╷╷╷╷╷╷╷

╷▉▉▉▉▉╷╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
╷▉▉▉▉▉╷╷
╷╷╷╷╷╷╷╷

╷╷╷▉▉╷╷╷
╷╷▉▉▉╷╷╷
╷╷▉▉▉╷╷╷
╷╷╷▉▉╷╷╷
╷╷╷▉▉╷╷╷
╷╷╷▉▉╷╷╷
╷╷╷▉▉╷╷╷
╷╷╷╷╷╷╷╷

╷▉▉▉▉▉╷╷
▉▉╷╷╷▉▉╷
▉▉╷╷╷▉▉╷
╷╷╷▉▉▉╷╷
╷▉▉▉╷╷╷╷
▉▉╷╷╷╷╷╷
▉▉▉▉▉▉▉╷
╷╷╷╷╷╷╷╷

Tada!

It looks like they’re even in the same order as is used in the character table. Like mentioned before, the vram or onscreen representation does not guarantee anything about how the data is represented internally. We are quite fortunate that the relationship between “position in the font” and “position in the character table” are so similar since it is less stuff to keep track of, but there was no guarantee it would be this way. DM4 stores its font in the same place.

Info

Gameboy graphics are usually more complicated than this. Since we’re only dealing with monochrome we’re able to ignore stuff about bitplanes, attribute tables, etc. Which are best explained by somebody else and won’t be discussed unless in a later section we find it impossible to avoid getting into.

As mentioned, DM4-Judah uses a character table similar to or the same as the one from DM3-En. It also uses the same font as DM3-en. With a bit of math and experimentation we can figure out which bytes correspond to the subset of the font changed between DM4 and DM4-Judah.

So, I do that: I find the parts that constitute “Judah’s font”. I copy their values from DM4-Judah and paste them into the corresponding locations in DM4. This unlocks a cool trick. We’ll call this modified rom “DM4-fonttest”. We can diff DM4-fonttest and DM4 to create a patch: a file describing how to produce DM4-fonttest when given DM4 as an input. That patch can be found here

Info

Creating the patch once you have the two versions of the file is not particularly interesting. Use a tool like lunarips to do this.

Note

I did this making the fonts embarassingly long ago, earlier this year. I think what I did was use imhex highlight patterns to annotate what ranges I cared about, then copied those ranges somehow. My project directory contains dm4-judah-glyphset.pattern, which is instructions for imhex on what ranges correspond to what characters. That file can be found here

So, now we are reasonably comfortable changing stuff and we’ve located and extracted the bulk of the text. Up next: translating it.

Purpose of /r/scams

r/scams is a strange place. A typical thread there goes sort of like this:

OP Fraud Fledgeling Posts: 1

Hey, guys, I got sent this dm on instagram and I’m not sure what to make of it. A “guru” wants me to buy and send him cryptocurrency for him to “invest” on my behalf. So, is this obvious scam a scam?

Redditor #1 Scam Spotter Posts: 69420

Yes, that is a scam.

Redditor #2 Ponzi Prodigy Posts: 419

crypto!

Automod Dehydrated Water Salesbot Posts: Lots!

AutoModerator has been summoned to explain fake cryptocurrency site scams.

Fake cryptocurrency websites and apps controlled by scammers are becoming more and more common. Sometimes the scam begins with a romance scammer who claims that they can help the victim invest in cryptocurrency. Victims are told to buy cryptocurrency of some kind using a legitimate cryptocurrency exchange, and then they are told to send their cryptocurrency to a website wallet address where it will be invested. Sometimes the scam begins with a notice that the victim won cryptocurrency on some website, in this case messages will often be sent through Discord. In either case, the scammer controls the website, so they make it look like there is money in the victim’s account on their website. Then the scammer (or the scammer pretending to be someone official who is associated with the website) tells the victim that they have to put more money into the website before they can get their money out of the website. Of course all of the money sent by the victim has gone directly into the scammer’s wallet, and any additional money sent by the victim to retrieve their money from the website will also go directly into the scammer’s wallet, and all of the information about money being held by the website was totally fake. This scam is also known as the pig butchering scam: https://www.reddit.com/r/Scams/comments/na8oax/asian_guygirl_from_online_dating_mentors_you_to/. If the scammer used Bitcoin, then you can report the scammer’s Bitcoin wallet address here: https://www.bitcoinabuse.com/reports. If the scammer used Ethereum, then you can report the scammer’s Ethereum wallet address here: https://info.etherscan.com/report-address/. You can see how much cryptocurrency has been sent to the scammer’s wallet address here: https://www.blockchain.com/explorer. Thanks to redditor nimble2 for this script.

Note

I spent sooo much time making the “fake forum posts” look right

r/scams is a community for discussing frauds & avoiding being defrauded. This is noble, but I think its purpose has a weird tension in it:

1. If a poster thinks to ask about something on /r/scams/, the poster probably expects they are dealing with a scam. As they figure it’s a scam, they don’t need /r/scams/’ help.

2. If a person being defrauded doesn’t think they’re being scammed, then they aren’t going to ask about this on /r/scams/, so /r/scams/ can’t save them.

I think this suggests that the range of situations where /r/scams/ is in a position to prevent a scam are pretty narrow. People definitely get value out of it regardless, of course.

Legitimate use of Noble Lie?

Pig-butchers often try to get their mark to interact with fake cryptocurrency investment platforms. These sites are pretty barebones. They’ll have some price tickers, a deposit button, and a customer support widget, and not much else.

People on /r/scams/ will sometimes give advice to crypto investment scam victims, that makes me raise an eyebrow. The OP will post something like this:

OP Scam Scion Posts: 1

My investment guru told me to download Coinbase and buy Bitcoin, and to then make an account on https://www.0a8c11bc1TradePro.tk, and to then send my Bitcoin from Coinbase to the address 0x10a8c11bc1TradePro. Did I get scammed?

and they’ll get a response like this:

Redditor Coin Disliker Posts: Several

Cryptocurrency is always a scam.

This is a strange response!

On one hand, there is a reasonable case for that nobody should buy cryptocurrency. OP certainly shouldn’t. OP will be better off if they categorically steer clear.

On the other hand, the point at which OP got scammed wasn’t when they downloaded Coinbase or even when they bought Bitcoin. They could have traded the Bitcoin for dollars and withdrawn the dollars, likely without issue. They got scammed only when they sent it to 0x10a8c11bc1TradePro.

Sending their coin to 0x10a8c11bc1TradePro is obviously a scam even in comparison to everything else in crypto. This distinction seems important to me. But telling OP about it might embolden them to deposit more and to then gamble it away or lose it trading shitcoins. Is it better if they don’t find out?

Omniscient 419 Scammer?

Scam emails, the sort that gmail automatically & silently junks for you, are written poorly. Here’s a representative excerpt from one:

WITH DUE RESPECT OF THIS HONORABLE COURT UNITED STATE SUPREME COURT UNITED STATES OF AMERICA, WE WANT TO INFORM YOU THAT WE HAVE DISCOVERED A TRANSACTION BETWEEN YOU AND AFRICA UNITS, ACCORDING TO THE INVESTIGATION MADE IT HAS COME TO OUR NOTICE THAT YOU ARE THE REAL BENEFICIARY OF THE SAID FUNDS ONLY THAT YOU WERE DEALING WITH THE WRONG ONES.

Terrible! Many have noticed this and asked why these are written so poorly.

The standard answer is “this is done intentionally, to filter out the skeptical, so the scammer doesn’t have to waste time responding to people who aren’t going to fall for it & won’t send money.”

This sounds reasonable, and it’s the sort of thing that would be really satisfying if it were true, but is it? The authors might just be sort of bad at writing American English.

Youtuber “Atomic Shrimp” gets into extended conversations with email scammers & many of these go pretty “off-script”. The different scammers tend to have a distinct voice & style & so on. And this voice persists across different stages of him “getting them off-script”. Which I think suggests that this is often just how the person writing the scam email, actually writes.

This makes a bit more sense to me than that an email about how “the IRS demands Steam gift cards!” is actually playing 4-d chess.

☞ This post contains ✨on-hover card images✨, indicated by the hanafuda symbol 🎴, like so: 🎴Thalia, Guardian of Thraben ☜

My dear girlfriend Alyssa—

Info

she can be found online in many places including her blog and twitter

—is indulging me by trying out tournament magic. She wanted to play something reasonably competitive & not have to spend a ton & to not have to make cuts to save on budget & for there to be a local scene. She picked pioneer.

I don’t play pioneer. I am okay at magic—

Info

I am an experienced amateur. I made mythic in each season I was active: 2019 March, 2019 May, 2019 June, 2019 July, 2019 October, 2019 December, 2023 January and 2023 May (pending). I also have an okay finish in a minor legacy tournament.

—and so I think maybe I can be helpful despite not playing pioneer. I made this overview of the format to help her pick a deck. She’s built UR Phoenix and is taking it to an event soon. I now attempt to help her sideboard. Read on for wild, uninformed speculation about UR Phoenix and the pioneer format in general.

The Deck

Note

Note from the future: this post, like all posts from 2023, are posts I recovered from my old blog and reposted in 2025. When this post was current, it also included a link to a scryfall decklist thingy for easy exporting. In the intervening years I deleted that decklist, so, no more link.

Here’s the deck:

Main (60)

Creature (9)

4 🎴Thing in the Ice // 🎴Awoken Horror

4 🎴Arclight Phoenix

1 🎴Brazen Borrower // 🎴Petty Theft

Instant (21)

4 🎴Consider

4 🎴Fiery Impulse

3 🎴Lightning Axe

4 🎴Opt

3 🎴Spell Pierce

2 🎴Spikefield Hazard // 🎴Spikefield Cave

1 🎴Galvanic Iteration

Sorcery (11)

3 🎴Chart a Course

4 🎴Pieces of the Puzzle

4 🎴Treasure Cruise

Land (19)

2 🎴Hall of Storm Giants

2 🎴Island

1 🎴Otawara, Soaring City

4 🎴Riverglide Pathway // 🎴Lavaglide Pathway

4 🎴Spirebluff Canal

4 🎴Steam Vents

4 🎴Stormcarved Coast

Sideboard (15)

Creature (5)

3 🎴Young Pyromancer

1 🎴Crackling Drake

Instant (8)

1 🎴Rending Volley

2 🎴Abrade

3 🎴Fry

2 🎴Negate

1 🎴Mystical Dispute

Sorcery (2)

2 🎴Brotherhood's End

General Remarks

You are a Xerox™ deck: you want to cast cheap spells, especially self-replacing ones (“cantrips”) to set up wins through 🎴Arclight Phoenix reanimations and 🎴Thing in the Ice // 🎴Awoken Horror flips for the beatdown.

You win by being able to interact profitably since you can do things you “already wanted to do” (e.g. cast 🎴Consider) and have it move you closer to objectives like “phoenixes in graveyard” and “three precombat instants and/or sorceries” that make you win. Interacting with the opponent & trading resources with them is usually good since you have a lot of card draw / card advantage.

You expect to spend the first few turns “setting up”: using the cantrips to get 🎴Arclight Phoenixs in the graveyard & durdling around until you have enough lands for it to be possible to cast three spells in a turn.

If you can, it is of course great to use the 🎴Galvanic Iteration on something expensive like 🎴Treasure Cruise rather than a mere 🎴Opt, but using it on a small spell is still fine.

Arclight Phoenix’ Ability And You

🎴Arclight Phoenix reads:

At the beginning of combat on your turn, if you’ve cast three or more instant and sorcery spells this turn, return Arclight Phoenix from your graveyard to the battlefield.

You want to look for opportunities to cast three instants or sorceries in your turn & before combat. Your opponent knows you are trying to do this and may try to stop you.

Our Meta

Our local meta is aggro heavy, and mono-blue spirits heavy in particular. Per the matchup matrix the UR Phoenix player is actually favored if they understand the matchup well enough.

This makes sense to me:

• blue is bad at exiling graveyards, so the phoenixes and delve targets are probably not going anywhere.

• you can accomplish your goals by casting nothing but 🎴Opt and 🎴Consider, and it’s really bad to counter an 🎴Opt or 🎴Consider most of the time

• Arclight Phoenix’ “return to play” ability doesn’t count as casting it, so it’s not like they can counter you.

• Arclight Phoenix has flying, can lethally trade with most spirits most of the time, and can be gotten back. One of Spirits’ play patterns is to play one spirit, put 🎴Curious Obsession on it, then attack like ten times with it, using the extra cards to protect the spirit and counter your stuff. This is only good if they’re able to do combat damage to you.

However: spirits has a lot of mechanics and many of them make it possible for an experienced player to trick the opponent. It’s important to know what the deck can do, so you can plan ahead around “if I do x, they might do y or z. Depending on which, I will do a or b…”. You not knowing they can give a spirit hexproof at instant speed, for example, would give them an advantage.

We’re going to tweak your sideboard to be very anti-spirits. Most Phoenix sideboards make more concessions to fighting ramp and control, but I’m not seeing these at our store.

Rules & Rulings & Conventions

• The copy made by 🎴Galvanic Iteration does not count as “casting” a spell

• The discarding done by 🎴Lightning Axe is a “cost”: it happens as you start casting the spell. So for better or worse the opponent can’t use counterspells to stop you from using 🎴Lightning Axe’s secondary cost as a discard outlet.

• The first thing that happens in the upkeep step is all the effects that say “at the beginning of your upkeep, do x” all go on the stack in FILO order. If you control simultaneous effects, you choose the order.

• The opponent is probably not going to help you by reminding you to take counters off of 🎴Thing in the Ice // 🎴Awoken Horror or reminding you to bring back the 🎴Arclight Phoenix. Everyone misses triggers sometimes. You get a lot of win% by making sure you remember the most important ones always. This will take practice. Use visual aids.

  • I’m going to make you a reminder card for tracking “precombat instants/sorceries cast this turn” so you keep in mind to think about whether to work towards reaching it that turn & how far you currently are. It may take getting used to; that is okay.

• The stack is FILO. If you try to use a lighting axe to kill something and the opponent responds by casting 🎴Rattlechains, then the Rattlechains will resolve first. Then its’ ETB hexproof-granting ability will go on the stack also ahead of the lighting axe, and by the time the axe resolves the target will have hexproof and so not get axed.

• “Can’t be countered” means countering it doesn’t do anything. It also means that countering-related effects such as “ward” (which usually counter stuff unless you pay the ward cost) don’t do anything.

• “Can’t be countered” does not go through hexproof.

General Tips

Try to look at spending your mana in terms of “how do I make the best use of the mana I get this turn cycle. Sometimes this means doing a lot of things in your turn’s precombat main phase to try to get back the phoenixes. Sometimes it means doing a lot of things in the opponent’s end step so you get to act as late as possible and/or remove counters from a 🎴Thing in the Ice // 🎴Awoken Horror. You want to preserve optionality

Notice what your opponent is trying to do. Are they spending resources on trying to find lands to make their land drops vs whether they are advancing their gameplan, etc. If they are struggling to just find their lands, be aggressive; they probably can’t counter your spell.

Failing that, do things that make the opponent play worse. Force them to make a lot of choices, so they have more opportunities to make the wrong ones. Winning is made out of scads of tiny edges and correct decisions made out of habit & reflex. People make a lot of mistakes. If you can make it look like they’re facing a critical choice, they will probably act like it and they might misplay. This works just as well if your hand is nothing but land: they may suspect a bluff, but they usually won’t know it is a bluff.

Think in terms of how many turns you are away from killing the opponent (your “clock”) and how different lines of play change or don’t change your clock. If using a burn spell on the opponent isn’t going to make them die any faster (e.g. it means they are at 1 rather than at 3) this usually means “don’t use it on them; just wait”.

Sideboarding

If killing their creatures doesn’t put you ahead then you probably don’t need things that kill their creatures. Killing a 🎴Bloodtithe Harvester doesn’t really set them back or you forward most of the time, so consider ignoring it.

Kill their 🎴Thalia, Guardian of Thraben on sight.

They’re going to try to exile the 🎴Arclight Phoenix in the post-sideboard games; consider not putting them in the graveyard unless you plan on reviving them very soon. Remember the 🎴Brazen Borrower // 🎴Petty Theft can bounce most permanents, including Leylines. Sometimes the opponent actually cannot recast it due to not running black mana. Sometimes they could recast it but one turn of graveyard access is enough for you to win. And if you pressure them enough, they might not be able to justify casting it.

Specific matchups

Green Devotion

This is the second most popular deck in the format. I don’t think I’ve seen it played at our store. Our sideboard is weak against them since we’re focusing so much on anti-aggro. If you do face them: their thing is to ramp a lot and then cast a huge thing that wins the game. For example: 🎴Storm the Festival.

The majority of their “bombs” are noncreature spells. 🎴Negate these. Check with them about how much mana they have or can make before you 🎴Spell Pierce.

Out: 2 🎴Pieces of the Puzzle

In: 2 🎴Negate

Rakdos Midrange

This is the most popular deck in the format. It’s pretty expensive so it’s going to be underrepresented but I think we have one player on it.

Their premier threat is 🎴Sheoldred, the Apocalypse. Save 🎴Lightning Axe for this unless you expect to win before their fifth turn since that’s when they’ll start drawing cards → gaining life → becoming ~unkillable via just having the Sheoldred.

They have a lot of removal and can generally drag us into a long grindy game. We take out things that aren’t impactful enough and bring in things that let us clog up or wipe the board.

OUT: 1 🎴Galvanic Iteration, 4 🎴Pieces of the Puzzle, 1 🎴Opt, 4 🎴Treasure Cruise

IN: 3 🎴Young Pyromancer, 2 🎴Negate, 2 🎴Abrade, 1 🎴Crackling Drake, 2 🎴Brotherhood's End

This might be “over-boarding”; feel free to do less if you want.

White Humans / Weenies

This is my deck! Bring in removal, especially boardwipes. Other than 🎴Brave the Elements (and some activated abilities on creatures) this deck plays at sorcery speed. Expect them to dump their hand into play quickly and to have minimal followup if you boardwipe. This matchup is about surviving the first few turns

Take out spell pierces and trim some copies of more expensive spells.

IN: 2 🎴Brotherhood's End, 3 🎴Fry, 1 🎴Rending Volley, 2 🎴Abrade

OUT: 3 🎴Spell Pierce, 2 🎴Treasure Cruise, 2 🎴Pieces of the Puzzle, 1 🎴Chart a Course

U Spirits

Know what their cards do beforehand. Here is an archetypal decklist; take a look

They’re going to try to play one spirit, put 🎴Curious Obsession on it, then attack like ten times with it, using the extra cards to protect the spirit and counter your stuff. This is only good if they’re able to do combat damage to you. Their creatures are pretty bad if you aren’t surprised by them.

The stack is FILO. If you try to use a lighting axe to kill something and the opponent responds by casting 🎴Rattlechains, then the Rattlechains will resolve first. Then its’ ETB hexproof-granting ability will go on the stack also ahead of the lighting axe, and by the time the axe resolves the target will have hexproof and so not get axed.

They’re allowed to “level up” the 🎴Ascendant Spirit at instant speed. Doing so uses the stack.

Your gameplan is the same as always:

1. survive the early turns as you get set up

2. flip a thing in the ice or reanimate some phoenixes for the win

Since their gameplan leads to them drowning in cards, you’ll want to kill their stuff. Do this EITHER when they are tapped out or right after they declare attacks.

Remember that 🎴Mystical Dispute counters everything in their deck for one mana. If you want to prepare even further, we could get you more of them.

I think 🎴Thing in the Ice // 🎴Awoken Horror is worse here since it cannot block flyers.

IN: 2 🎴Brotherhood's End, 3 🎴Fry, 1 🎴Rending Volley, 2 🎴Abrade, 1 🎴Mystical Dispute, 1 🎴Crackling Drake

OUT: 1 🎴Galvanic Iteration, 4 🎴Thing in the Ice // 🎴Awoken Horror, 2 🎴Treasure Cruise, 2 🎴Pieces of the Puzzle, 1 🎴Chart a Course

Note

Want to keep 🎴Thing in the Ice // 🎴Awoken Horror in? Do what you think is best, of course. I’d look into running more 🎴Crackling Drake after all and bringing them in for this, I think. It even lives through 🎴Brotherhood's End!

Generic Control

Take out burn spells such as 🎴Spikefield Hazard // 🎴Spikefield Cave & 🎴Fiery Impulse

Bring in counterspells and things that generate value e.g. 🎴Crackling Drake & 🎴Young Pyromancer

Generic Aggro

Take out expensive spells that you won’t have time to cast before dying. Feel free to take out one of each of a few things.

Bring in all the removal: burn spells, boardwipes. Remember that if your third noncreature spell is 🎴Brotherhood's End, you could wipe their board and then get all your Phoenixes back in that same turn

Generic Combo

Burn spells out

Counterspells in

Convoke / Loxodon Hierarch Aggro

Burn and boardwipes in

Expensive spells out

Conclusion

Good luck!

Vertical space is better than horizontal space and you should guard it jealously.

Why it is better:

• Most experiences people have on computers don’t need much horizontal space

• Most experiences people have on computers are infinitely tall.

What you can do about it:

• Get treestyletab and hide the horizontal tab bar.

on configuration

If your job is “using a computer”, you owe it to yourself to spend some time shaping your workspace into your ideal shape. If you routinely get annoyed at something in your workflow that you plausibly could configure your way into eliminating, you really should do that. Make computers do “tasks fit for computers”; don’t do them yourself on the computer’s behalf.

on browser tabs

The browser tab was invented in 1998 for SimulBrowse.

Note

Installer found courtesy of Evolt (later renamed NetCaptor)

Tab behavior and presentation is nearly identical to now. SimulBrowse looked like this:

The only significant difference between tab behavior then and now is: in the original version, the tab screen overflow behavior is “the tabs spill off of the side of the screen”. They don’t compress horizontally as you open more of them. You can look at different parts of the tab bar by clicking the ◂ and ▸ arrows found to the right of the tab bar:

No later than 2004—

Note

Which is way before most people started using tabs. the typical person probably started sometime around Firefox 2-3 (late 2006-early 2008) if they were ahead of the curve, or with the launch of Chrome (mid 2008) if they weren’t Into Browsers enough to have tried early Firefox. In other words, in short, for the overwhelming majority of people, tabs have never changed at all.

—the “tabs compress as you open more of them” behavior was invented. Firefox 1.0 (2004) has this; some earlier browser might also. “No later than 2004” is the last time the tab user experience has meaningfully changed. Two features of browsing that are poorly served by contemporary tabs:

1. Browsing is hierarchical; you start in one place and you carve a path through hyperlinks, possibly opening a few additional tabs from each page you visit. “Where you accessed something from” is a natural, useful signpost in keeping track of what you’re up to. The tab bar is flat, so it can’t capture this information.

2. Browsing is about abundance; you’ll probably open dozens of tabs in the course of doing anything deeper than cursory research. Doing so squishes the tabs or drives them offscreen or both; it’s difficult to have a decent quick reference of “what do I have open”. Some examples:

   • 

     Thirty tabs open in chrome: perhaps in the moment you can mostly keep track of what each thing is based on the favicon and first two letters and relative location on the bar?*

   • 

     Forty tabs: you get favicons and relative locations. nothing else

Lemma: the horizontal browser tab bar is a historical accident and doesn’t scale well with heavy use.

on horizontal and vertical space

Vertical space is nearly arbitrarily valuable. Most of what people do on computers is browse endless feeds. How much feed you can skim at once is mostly bounded by how tall the viewport can be, which is bounded by the screen resolution minus any operating system and browser cruft.

Note

To take it a step further: how much you can skim at once is actually bounded by your eyeballs. Adding more pixels etc doesn’t help if you’re saturating your eye already.

The activities that aren’t browsing endless feeds are still mostly vertically constrained. Programmers generally limit themselves to 80ish characters per line, so any one view in their text editor or IDE doesn’t benefit from being any wider. File/project explorers and in-window terminals/debugger consoles can generally be moved to the sides if they aren’t already there by default.

Regardless of what you’re up to, giving yourself more vertical space to do it in will probably make the experience better.

Lemma: getting rid of the horizontal tab bar and repurposing its space might be nice.

Horizontal space is considerably less valuable. I see three reasons for this:

• Human horizontal vision is wider than the vertical vision.

You can fit more things in it, so a unit amount of it is less precious.

• Many activities are chat apps. Chat apps are thirsty for vertical space and are borderline indifferent to horizontal space.

Each message in a typical chat app is allocated at least one vertical “line” regardless of its length. The horizontal space of that line is filled with the message. If it’s a short message, the rest of the horizontal space is left unused. If the message is too long to fit on one line, it gets word-wrapped across however many lines it requires.

Most chat conversations word-wrap very well. Most of the messages are way shorter than one “typical screen-length line”, so there’s lots of unused space after the lines. Consider the following anonymized discord conversations, presented in portrait and landscape view.

One of these screenshots was taken on my landscape-oriented 1920x1200 monitor:

The other on my (identical but rotated 90°) portrait-oriented 1200x1920 monitor:

The latter is able to show about twice as many lines (use the black box present in both images as a landmark if you’d like to check) despite having the same pixel count. This is because it doesn’t have to spend tons of screen space on “the non-content between the end of the message and the right edge of the screen”.

• Activities that aren’t chat apps often limit themselves to relatively narrow widths and that’s probably for the best.

If you have an ultrawide monitor you probably never open up a plaintext document in fullscreen with no wordwrap and then read the document using the entire monitor. That monitor is useful for multitasking and movies, but you would probably not display or read a book on that monitor as one giant window. It isn’t suited for “read from left to right, then at the end go all the way back to the left and down by one, then repeat”. The distance between the start and the end of the lines is too large for this to be a good experience so people don’t do it.

Websites figure you don’t want to do that and won’t let you. Below is an (anonymized) screenshot, this time of what I see when I visit twitter. This is as viewed on a typical 1920x1080 monitor:

a third of the viewport is dedicated to horizontal padding!

Twitter doesn’t want you to view it in ultrawide. It responds to being fed more space by wasting more of it. It is pretty typical in this regard.

Reddit is an endless feed. Adding more horizontal resolution to the viewport doesn’t allow it to show you more posts since it can only show one post per row. Nor does it allow you to view more comments at once since reddit also softwraps the commments to ~100 characters per line. Reddit is, in effect, a SPA designed for very tiny screens. Most websites, static or not, follow similar design principles.

Lemma: a lot of people have horizontal regions of screen space that usually aren’t being used for anything in particular.

thus: treestyletab

Check out my UI; it makes such elegant use of space by putting a tab tree in a sidebar and not having a tab bar at all:

Note

Eschewing an address bar is a bit too radical for my tastes so “just browse in fullscreen mode” isn’t quite right. If I really want to hide the tree, F1 toggles showing/hiding it.

Giving a robust tutorial for replicating this arrangement would involve writing way more, but the bullet point version is short. To get this UI, use Firefox, with:

• the treestyletab extension (provides the tree)

• the toolkit.legacyUserProfileCustomizations.stylesheets flag enabled in about:config (makes it possible to hide the tab bar)

  ::: note You’ll need to restart Firefox for this change to take effect. You’ll also need to restart for any changes in userChrome to take effect. :::

• the following rules in {FirefoxProfileFolder}/chrome/userChrome.css to actually hide the horizontal bar:

  ::: note If you’re following along and can’t find the folder: go to about:support and check the entry for “Profile directory” for its location. :::

#main-window[tabsintitlebar="true"]:not([extradragspace="true"]) #TabsToolbar > .toolbar-items {
  opacity: 0;
  pointer-events: none;
}
#main-window:not([tabsintitlebar="true"]) #TabsToolbar {
    visibility: collapse !important;
}

#sidebar-box[sidebarcommand="treestyletab_piro_sakura_ne_jp-sidebar-action"] #sidebar-header {
  display: none;
}

Most people use Chrome, which so far as I can tell doesn’t allow modifying the UI to hide the original tab bar. People have made Chrome extensions that supplement the bar with a shortcut-invokable tree popup, which isn’t what I’m used to, but has its own kind of charm. Regardless: consider demanding a better tab experience from your favorite browser. We can do better than The Bar.

Magic and Magic-related websites have a problem: a lot of their links don’t work! In some cases, this is understandable. For example, “the dojo” has been defunct for twenty years, so it is perhaps unreasonable to be mad at them for the original link to “who’s the beatdown” breaking.

Other cases are harder to understand.

• In Magic Arena, in the shop, until very recently, the in-app link to the page on Wizards of the Coast’s site about pack droprates, was broken, and had been wrong for months. The link provided in Arena was this one; the information on the website was actualy over here.

Note

These days, the in-app link works and points here

• On the Wizards of the Coast’s website, links to other parts of the Wizards’s of the Cost website sometimes don’t work. This list of articles has an entry named

Week #397 (August 4, 2009) – “Designing for Johnny”

The link points to here, which 404s. Searching for a working link via google didn’t go turn up anything. Searching via DuckDuckGo worked and turned up this. So, at some point wotc changed their article url pattern from /articles/archive/foo to /news/making-magic/foo, but also changed the article publish date?

That article is pretty old, but, it’s not like its dead content or anything. Mark Rosewater’s posts link extensively to his older posts, which is why I ended up finding the above oddity. The big vendors do these site reorganizations that change the location (or remove entirely) older articles and then don’t update the links to those articles to match the new location. It’s pretty hit or miss whether the on-hover card images in a given article will work five years down the line.

It’d be nice if the community would stop migrating all its strategy discussions and resources into the unindexable Discord walled garden, too. I figure doing so is at least partially a response to “stuff on Magic websites is too impermanent”, but, Discord-hosted content can be fragile too and there’s less recourse if something goes wrong.

I’m not really sure what the solution here is. Maybe there could be a browser extension, where you give it a whitelist of websites, and on those sites if you try to access 404ed content, the extension Googles or DDGs for terms that ought to find a working link to the content, and serves up the search results, or seamlessly takes you to the first result.

☞ This post contains ✨on-hover card images✨, indicated by the hanafuda symbol 🎴, like so: 🎴Thalia, Guardian of Thraben ☜

This post’s examples are (with one) about the first Pokemon set - the Base Set - exclusively. The base set was, for little while, the only set. A short while later, two more sets came out: Jungle and Fossil. These three were the cardpool for the first notable competitive format, descriptively named “BJF”, short for “Base/Jungle/Fossil”. It’s a bit weird to try to size up the base set on its own since it wasn’t played without Jungle or Fossil for that long. But the BJF sets are all fairly similar in terms of balance: trainers are strong; non-evolving pokemon are stong; other things are weak. The general design trends still hold, even if trivia like “what percentage of the cardpool is trainers” changes a bit when you bring Jungle and Fossil into the picture.

I am going to explain mechanics by alluding and comparing to what Magic does.

game design

At the beginning, Pokemon had one set; the Base Set. We can look at its composition to make reasonable guesses about what the designers were thinking. If they emphasized a mechanic (featured on lots of cards, or rarer ones, or shinier and/or cooler ones, or it gets allocated a lot of the rules-space) then there’s a good chance they thought it was important.

It looks like the core mechanical selling point was supposed to be about a rising power level over the course of the game via the evolution mechanic. The way evolution works is, you can use later, stronger evolutionary stages of a given Pokemon, but fonly if you already have the unevolved form in play, and only if it has survived at its current stage for at least one turn already. Some Pokemon evolve no times, some once, and some twice. The cards have rarities; the packs they came in would come with more commons and fewer rares. Second-stage evolutions were pretty much exclusively found at the highest rarity and made up much of the rare pool. There were a few fancy, shiny foil-art cards; all of them Pokemon, most of them second-stage evolutions. The marketing I remember seeing as a kid was about getting to use evolution to play a 🎴Charizard. Evolution is flavorful; it’s cool; it’s strategically awful.

Note

Evolution was bad at the time. It might be good now.

Info

Aside: the first set has 102 cards. The card-type breakdown is 69 Pokemon, 26, trainers, 7 energy. The trainers focus on lots of different mechanics. A mere two of them (🎴Devolution Spray, 🎴Pokémon Breeder) are “about” evolution and an additional handful could benefit evolution-based strategies but weren’t about them. It’d be fair to say trainers are not intended to be “about” evolution. Pokemon, however, are about evolution. 53/69^(77%!) of them evolve or are evolved. Of the quarter that don’t have evolutions, a bunch gain them in Jungle and/or Fossil. This game is “about evolution”.

Evolution could be great if the evolved forms were sufficiently stronger (more health, more damage per energy, more raw damage) than the non-evolving Pokemon. They aren’t; evolving isn’t profitable. Your attacks get stronger, which is flashy and cool! But your attacks also get more expensive, which is a huge problem and makes it impossible to actually do damage.

An important idea in trading card games: over the course of the game, the amount of “swinginess” that happens in each turn should increase. The first turn should have puny little effects that represent tiny swings in “who is winning”. Later turns should have increasingly large effects & so large swings in “who is winning and by how much”. Analogous maybe to the “material advantage” bars shown by chess apps? Most collectible card games have a mechanic meant to achieve this.

• Magic has “you need mana to cast spells. You get mana from lands. You can play one land per turn. Thus, you can do more expensive (and therefore stronger) things the longer the game goes on”.

• Hearthstone has “you need mana to cast spells. You have a mana pool. It starts at one mana. Each turn, its capacity increases by one, and then it refills completely. So on turn one you can cast a one mana card. And you must wait until turn ten to can cast a ten mana card”.

• Yu-Gi-Oh has the mechanic of “you need creatures to win. You can play one creature per turn. Larger creatures require you to sacrifice in-play creatures. So, large creatures cost cards and time.”

• Pokemon has energy cards. You can play one energy per turn. Energy are attached to a specific Pokemon. To use an attack, you must have some minimum amount of energy. Stronger attacks generally have higher energy requirements.

Destroying an energy in Pokemon is loosely analogous to destroying a land in Magic.

Roughly a quarter of every competitively viable early Pokemon deck consists of uncounterable zero-cost 🎴Stone Rains! Every sixty-card deck contains four of each of the following: 🎴Energy Removal (destroy an energy), 🎴Super Energy Removal (destroy two energy), 🎴Item Finder (graveyard recursion for your energy removals), and 🎴Computer Search (unconditional tutor/search library for whatever card you want; can find an energy removal).

We know that every viable deck runs the maximum allowed amount of the above cards, since blowing up your opponent’s resources is pretty much the strongest thing you can be doing. In fact: every viable deck has something like thirty cards (half of the deck!) in common with all other viable decks, since there are so many overwhelmingly generically powerful effects in the format.

Attacks must be cheap to be viable, since your opponent is going to be constantly destroying your energies. Attacks of evolved Pokemon are expensive; they’ll often cost three or four energy pips. Evolutions overall are too hard to get into play and too easy to end up unable to act due to lack of energy. The more reliable strategy is to pick from a shortlist of powerful non-evolving options: 🎴Hitmonchan of 🎴Electabuzz 🎴Mewtwo 🎴Chansey. The next two sets, Jungle and Fossil, were designed similarly: they added many Pokemon, but the ones with competitive relevance continued to be efficient non-evolving Pokemon (🎴Moltres 🎴Magmar-🎴Scyther 🎴Mewtwo); The Jungle and Fossil additions didn’t change the “evolved is a really big downside” dynamic.

Pokemon had large competitive tournaments almost immediately after it was brought to the US. This is unusual for a new trading card game; it’s common for competitive support to emerge only later. In the case of Pokemon, this early competitive support means lots of people got to go to tournaments and experience playing against “a deck consisting of efficient non-evolving pokemon and energy destruction”!

Sometimes, a contemporary writer will try to cover “the early Pokemon trading card game’s metagame” and will list a few strategies. They’ll generally be left scrabbling to find strategies that aren’t “just use the efficient non-evolving ones”; they’ll likely mention the 🎴Blastoise/Rain Dance strategy, 🎴Wigglytuff/“Do the Wave”, and if they’re especially good researchers then they may talk about Moltres + Chansey Stall/Mill. The latter two archetypes are pretty good, too. Rain Dance is rather bad, though. Back in the late 90s, people hadn’t figured this out, so contemporaneous sources would talk about it being good. It turns out, “being able to play as many energy as you can access, if you can evolve”, is a fragile strategy! You might not find your combo pieces. You might get forced to start the game with just a 🎴Squirtle; you plausibly get one-turn killed by a lot of unevolved-pokemon-deck’s opening hands in this situation.

For the curious, there are strategic resources out there specifically about the earliest Pokemon formats. There is a very cool Discord server, also focused on retro Pokemon formats, particularly base-jungle-fossil. If you aren’t put off by the strong non-evolving Pokemon and the rampant land destruction, you actually can play this (twenty years out of date!) format, in paper, via webcam, on that server. It’s part of a recent broader trend of forming communities for webcam-based play for older or less accessible trading card game formats. There’s one for legacy Magic, too.

conclusion

Parting thought: check out my BJF decks! The discord server I mentioned in the previous paragraphs holds monthly tournaments; the registration process involves submitting a decklist via taking a picture of your deck all splayed out. These pictures were taken for that purpose.

In cases where I didn’t have a desired card in time for the deck registration photo but expected I’d have it in time for my actual matches, I sometimes used proxies. So there are a few obvious “fakes” in these. I still think they’re cool, though:

☞ This post contains ✨on-hover card images✨, indicated by the hanafuda symbol 🎴, like so: 🎴Thalia, Guardian of Thraben ☜

I was born a bit too late to play Magic on-release. I was one year old at the time, so, I probably wouldn’t have had the dexterity needed to shuffle effectively. I was born at just the right time to catch the beginning of some other card games, though: Pokemon and Yu-Gi-Oh. This post is about localization trivia about the latter.

This post is about the “Yugi-Kaiba Format”. Many of the rough edges discussed aren’t true anymore, and some of them stopped being true very quickly.

I am going to explain mechanics by alluding and comparing to what Magic does.

the manga

Yu-Gi-Oh is a card game, based on an arc from a manga also titled Yu-Gi-Oh. The plot of every early Yu-Gi-Oh chapter is as follows:

1. Introduce someone comically evil. Evil person threatens Yugi (the protagonist) and/or his friends

2. Introduce a game. Yugi and the evil person play that game with life or death stakes

3. Yugi wins; his opponent is driven insane or dies

In Yu-Gi-Oh (the manga), one of the games in one of the arcs is called “Duel Monsters”.

Info

Duel Monsters is, in some early material, referred to by the less catchy name “Magic and Wizards”.

It didn’t have fleshed-out rules since it did not exist outside of the story, and the story isn’t really about Duel Monsters’ mechanical details. Yu-Gi-Oh (the card game) is based on Duel Monsters. The card game was produced by … 🥁… Konami, a famous Japanese game publishing company.

konami

Konami has some to-my-knowledge uniquely terrible labor practices^{1 2 3}! One of these practices is this one-two punch:

• not crediting artists for their work on card illustrations

• requiring all artists to sign NDAs! artists are not allowed to take credit for their work in any way

The “vibe” is, “by fiat, this game is a black-box created by Konami™. it does not contain artistic flourishes or influences by individuals.” This sort of a labor culture is not conducive to getting much primary source material about what working on the game was like, and why a design decision was made, which is a shame. There’s a wealth of information out there about how Magic is made now & how it was made in the past. I’m told some similar resources exist for Pokemon, though I don’t know this for sure.

jargon

Like many games, Yu-Gi-Oh has a bunch of jargon for its game concepts - kinds of cards, parts of cards, parts of turns, etc.

Yu-Gi-Oh lifted a lot of its gameplay elements from Magic one-to-one and just gave them a new, slightly different name. Examples:

• Power ⇒ Attack

• Combat ⇒ The Battle Step

• Upkeep ⇒ Standby

• Sacrifice ⇒ Tribute

They mostly did a thorough job of not 1:1 using Magic jargon. Except for how they named one of their card types: “Magic card”. Weird oversight! This was later retconned or renamed or amended to “Spell card”. It’d be cool to know what the deal is with this, but, due to how Konami’s implicit position is that the game does not have artists or a development process, probably we will never know.

relevant game mechanics

I am going to explain mechanics by alluding and comparing to what Magic does.

Quoting myself in “Pokemon Trading Card Game” design review:

An important idea in trading card games: over the course of the game, the amount of “swinginess” that happens in each turn should increase. The first turn should have puny little effects that represent tiny swings in “who is winning”. Later turns should have increasingly large effects & so large swings in “who is winning and by how much”. Analogous maybe to the “material advantage” bars shown by chess apps? Most collectible card games have a mechanic meant to achieve this.

Yu-Gi-Oh has the mechanic of “you need creatures to win. You can play one creature per turn. Larger creatures require you to sacrifice in-play creatures. So, large creatures cost cards and time.”

Yu-Gi-Oh doesn’t have mana. Most cards can be cast for free; the main resource, so far as I can tell, is card advantage. The pace / swinginess of the game is mediated by “normal summoning” and “stars”.

• Normal summoning: you can play no more than one creature per turn. Loosely analogous to how in Magic you can play only one land per turn. Much like Magic’s land drops, there are ways to get around this “one per turn” limitation & play more creatures.

• Stars: some creatures have a sort of psuedo mana-cost. Each creature has an immutable stat, its amount of “stars”. Things with a lot of stars are, (and these are the only game objects this is true of), not free. They cost “sacrificing some number of creatures”! Here is a list explaining what star counts correspond to what additional costs:

  • 1★ to 4★: no additonal cost!

  • 5★ to 6★: one sacrifice

  • 7★ to 8★: two sacrifices

Observations:

• There are three “tiers” of starriness, based on how how many sacrifices it costs to play the thing. You might expect there to be some sort of a functional distinction between, for example a 1★ and 4★, even if they both can be played for free. There is no such distinction. For all rules purposes a 1★ and a 4★ are exactly the same. weird! The cards in the manga have stars on them, roughly indicating how strong they are but otherwise having no associated mechanics. That’s why there are so many star amounts; they were flavor that had to be retrofitted to make them do something in an actual game.

• I did a little bit of a fib when I wrote the above “stars to costs” table. On actual Yu-Gi-Oh cards, the stars are not represented by putting, e.g., “8★” on the card somewhere. Having 8 stars is represented by displaying 8 ★ symbols in a row. Humans can’t easily subitize past four of something, so, figuring out how many stars something has by reading the card is a pain in the ass.

  In light of this, I’m going to redraw the “star to costs” list now, but this time I’m going to template it the way actual Yu-Gi-Oh cards present this information. I hear these days they’ve added creatures that have even more than 8 ★, so, good luck with that:

  • ★ to ★★★★: no additonal cost!

  • ★★★★★ to ★★★★★★: one sacrifice

  • ★★★★★★★ to ★★★★★★★★: two sacrifices

Got it? Good!

• Wow! “two sacrifices”!? Those are some steep costs. You’re committing an extra two cards and two turns worth of summons, to cast your big shiny 7-star thing. There is no way this could be worthwhile to do. On one hand, a big expensive creature could be valuable if it sticks around for more than a turn. It might get to attack many times and so destroy several opposing creatures, which would be value, card advantage, etc. On the other hand, there are lots of 0-cost spells that basically read “destroy target creature”, so, the expensive creature won’t be able to do this.

localization

Yu-Gi-Oh’s first English-localized set is titled “Legend of Blue Eyes White Dragon”. I am going to refer to it as “E1”. When I talk about the first Japanese set (whose official name is “Vol.1”), I’ll be referring to it as “J1”. J1 and E1 are radically different.

E1’s contents don’t make much sense. It has 126 cards, here is their type breakdown:

╿ 126 cards
├─╮ 87 creatures
│ ╰─╮
│   ├─╮72 vanilla
│   │ ╰─╮
│   │   ├╼ 60 1★ to 4★
│   │   ├╼ 6  5★ to 6★
│   │   ╰╼ 6  7★ to 8★
│   ├╼ 1 "effect"
│   ├╼ 4 "flip effect"
│   ╰─╮10 "fusion"
│     ╰─╮
│       ├╼ 6 1★ to 4★
│       ├╼ 3 5★ to 6★
│       ╰╼ 1 7★ to 8★
├─╮ 36 spells
│ ╰─╮
│   ├╼ 15 "normal"
│   ├╼ 15 "equip"
│   ╰╼ 6 "field"
╰─╮ 3 traps
  ╰─╮
    ├╼ 2 "normal"
    ╰╼ 1 "continuous"

I manually sorted the cards into these buckets to make the chart. I think visualizations like this are cool; I think it’s a shame there aren’t better automated tools for querying stuff like this.

mechanical oddities:

• Stars (★) use an 8-point scale to represent a total of three possible states (“costs 0 sacrifices”, “costs 1 sacrifice”, “costs 2 sacrifices”).

• Half the set consists of zero-cost vanilla creatures. They come three flavors:

  1. their attack/defense are roughly ⚔100/🛡100

  2. their attack/defense are roughly ⚔0/🛡2000

  3. and “their attack/defense are roughly ⚔1500/🛡1500

  It is weird that they want to spend sixty creatures worth of space in the set on expressing what are basically three ideas, especially since #1 is so underpowered nobody would want to use it.

• About 10% of the creatures are “fusions”. Fusion is a mechanic where you can summon specific creatures from out of your sideboard & without it costing you your summon for that turn. To do this, you cast a specific spell, 🎴Polymerization, and sacrifice-or-discard two specific (as in, each fusion card lists exactly two other cards it is fused out of) other monsters as “fusion material”. Wow! Those are some steep costs. You’re committing three specific cards to do this, you need to find all three of them, one of those cards does nothing on its own, and the other two have no particular selling point other than that they can be used for this.

  If you get a fusion out of a pack, you can’t use it unless you own the other three cards. If you get any fusion, you can’t use it without a polymerization. Polymerization is at one of the higher rarities; there is no particular reason you would expect to own it unless you went out and bought it third-party, which at this point is done out of mail-order magazines.

  Fusions aren’t meaningfully stronger than their component material. They’re slightly stronger than their components, but the components are often really bad. You can often play stronger things of a given cost for free.

Much of the strangeness is downstream of how E1 is not “an english translation of the first Japanese set”. E1 is “assorted cards sourced from various sets printed in the first year and a half of the Japanese game”. And during the timeframe those sets were printed in, there was a fuckton of power creep.

The first Japanese set comes out in January of ’99. Sets continue to come out at a rate of about one per month. Which might sound deliriously quick to someone used to the Magic standard-legal set release schedule, but, these sets are small; 40-50 cards small. They’re also fairly reprint heavy.

• Fusion: The first set’s creatures are all vanilla. The second set introduces the first “not a vanilla creature” creature idea: fusion. Why does fusion get away with requiring you own a suite of four cards? Because it was way more plausible that “every player that wants this card, has it” when there are a total of like fifty unique cards in your game. Why does the mechanic seem sort of weird and weak? It was in the manga; they didn’t want to deviate from how it worked in the source material too much. It just, is not a very strong mechanic.

Note

I am a bit curious about just how much each of these early sets overlaps with the other ones. The information is out there but it I don’t think anyone has actually analyzed it in this way. For that matter: I don’t think there are any tools quite on Scryfall’s level, here.

Regardless: Japanese Yu-Gi-Oh got lots of new sets over next few years. One of these sets came out in August of ’00. E1’s cards were sourced from Japense sets released between January ’99 and August ’00. That’s a year and six months and probably twenty or so sets and a few hundred cards.

Note

Checking the exact number of sets is hard, due to the aforementioned lack of good tools

• J1’s strongest 4★ has an attack of ⚔1200. The set contains three ⚔1200 creatures. J1 had exactly one 4★; the limited cardpool forced you to include some 3★s and probably some 2 and/or 1★s also. The player probably does not have the ability to field playsets of all the ⚔1200 creatures anyway since there are no card shops or vendors other than “the vending machine the packs come from”.

By the time all the sets drawn on in E1 set had come out, the power level for a ≤5★ had risen considerably, in terms of how strong the individual options were, and in how many options existed. You no longer had to include a bunch of bad stuff just to reach the deck size requirement.

As for how the cards selected for inclusion in E1 were selected: my best guess is that the localizers were selecting for iconic-ness and for hitting a target amount of cards at each amount of ★s, even though at this point 1★ 2★ and 3★ were now basically design relics rather than meaningful content in their own right. The same is probably true of the fusions. It certainly wasn’t done to improve the play experience or average competitive relevance of a typical pack.

• The names on the cards are weird: this was often done in localization & not present on the originals! 🎴Steel Ogre Grotto #1’s name in Japanese is 鋼こう鉄てつの巨きょ神しん像ぞう, or Kōtetsu no Kyoshinzō, or “Giant Idol of Steel”. Very sensible! In english we get a silly name. Another card in a later set gets renamed from “Iron-Fist Golem” to “Steel Ogre Grotto #2” to make sure the numbering isn’t done in vain. Baffling. I don’t really have a take on why this was done; I just think it’s interesting and would be easy for a casual observer to miss.

conclusion

Making a game is really hard.

resources

Format Library is a cool resource.

Goat Format is the most popular retro format.

Fandom.com’s ads are egregious and their business strategy means they’re the top—and often the most convenient—result for most media property related searches. Your options are to use e.g. ublock origin to block annoying page elements, or to use a wrapper service like those made easy to use by Indie Wiki Buddy to handle this hiding for you.

If you want to go the ublock route, filters for the extension are created like so:

Use filters that are something like this:

! 2023-02-10 fandom.com
fandom.com##.global-navigation
fandom.com##.WikiaRail.right-rail-wrapper
fandom.com##.mcf-wrapper
fandom.com##.global-footer
fandom.com##.page__right-rail
fandom.com##.render-wiki-recommendations > div
! 2023-02-12 fandom.com
fandom.com###WikiaBar
fandom.com##.is-visible.fandom-sticky-header
fandom.com##.marketing-notifications
fandom.com##.page-footer
! 2023-02-12 fandom.com mobile-specific
fandom.com##.recirculation-prefooter
fandom.com##.article-footer

eHow

Content farming is as old as dirt. Getting on lots of high-ranking search results at low cost is a winning strategy for getting lots of ad views. So, the thinking is, users might like it if you spend lots on making the site great, but their liking it doesn’t bring in ad money commesurate to the effort. So, the farmer wants to make their content as cheaply as possible; the content being useful is but unnecessary. So you pay people $15 an article to write articles like “How to Put on a Speedo” and Google dutifully rewards you with the top result for 🔎 » "how to put on speedo".

In this way, for a few years, eHow took over google search results, and mass-producing content-for-eHow became a semi-popular form of online menial labor. This was until about a decade ago. Today’s search result quality problems are a bit more subtle than yesteryear’s “Google=eHow”. Drowning the world in content nobody wanted to read or to write might work but it’s a lot harder to make it work when your host is trying to discourage that sort of thing.

Fandom dot inc

Fandom (né-wikia) is a wiki hosting service. It was cofounded by Jimmy Wales (of Wikipedia fame). It has been aggressive about acquiring other wiki hosting services. You’ve probably seen one of their holdings in the results if you’ve ever searched about a popular media franchise.

I think their overall strategy is shaped pretty similarly to eHow’s: as cheaply as possible be the top search result for as many questions as possible. Though these questions are trivia like 🔎 » "what country is bandit keith from" rather than tutoral questions like the aforementioned 🔎 » "how to put on speedo". The content is even made for free by enthusiasts, which is a pretty sick deal. None of this is a problem; it’s a pretty clever business to be in!

Info

The google infobox currently gets this wrong due to how the “abridged series” fanwork gets this wrong as a joke, and that fanwork has a wiki.

The thing is, Fandom uses hella advertising on its pages. The user experience on their pages is terrible. Look at this nonsense:

The first image is a full-page screenshot of a page on a fandom wiki as its owners intend it to be seen. The second image is a map of the content on that page. The green is content, the black is advertisements and cruft. You really should use an adblocker. Even the FBI’s position on this is “you, the user, should use an adblocker when going online”.

If you install ublock origin and turn on the top one or two default filters, and try again: there’s less advertising, but half of the vertical length is still intrawiki advertisements, a lot of the horizontal length is cruft and more advertisements, and there’s an autoplay video advertisement down in the lower right corner. It’s really not a good scene and I’d strongly recommend filtering out the crap.

Here is a comparison, of what the page looks like with no filtering, with “standard filters”, and with the additional filters I’m using:

This could surely be improved on; I don’t even remove the padding allocated to the orange bar on the left. There is so much space on these pages just waiting to be put to useful purpose.

Benchmarking

There isn’t much of a page size or load speed difference between the “some adblock” and “more adblock” views. The results for each are shown here:

Try it yourself

Most browsers’ dev tools can show this; in Firefox: f12 → network → ☑ ‘disable cache’ → f5.

The “more adblock” view pulls in about 2/3 as much stuff as “some adblock”, but both decompress to being of roughly equal size anyway. They finish loading at roughly the same time. Both blow the unfiltered version out of the water, in the sense that without adblock, the page continues loading more advertisements in the background forever. Below are two screenshots taken at arbitrarily-selected points after the visible content was finished loading.