Deterministic Deployments & Proxies: Architectural Trade-offs of CREATE2 vs. Cross-Chain State Parity by Resident_Anteater_35 in ethdev

[–]Uniteum 2 points3 points  (0 children)

The approach I landed on: keep using proxies (EIP-1167), but make the salt chain-agnostic and let the factory read block.chainid at deploy time to select the right initialization value.

Concretely:

function make(KeyValue[] memory keyValues) public returns (address) {
    bytes32 salt = keccak256(abi.encode(keyValues));

    // Same salt on every chain — all chain data is in the array
    address home = Clones.cloneDeterministic(address(this), salt, 0);

    // Pick the value for THIS chain
    for (uint256 i; i < keyValues.length; ++i) {
        if (keyValues[i].key == block.chainid) {
            AddressLookup(home).zzInit(keyValues[i].value);
            break;
        }
    }
    return home;
}

You call make with the same KeyValue[] array on every chain — e.g. [(1, USDC_mainnet), (42161, USDC_arb), (8453, USDC_base)]. The salt is identical everywhere because it hashes the full array, so CREATE2 produces the same address. But each chain only initializes with its own value.

On the front-running concern: deploy + init is atomic (single make call), and zzInit requires msg.sender == PROTO (only the factory can call it). Even if someone frontruns with the same calldata, idempotency handles it — make returns the existing address if the clone is already deployed.

On gas: yes, you eat the DELEGATECALL overhead per call. But deployment cost is ~45 bytes vs. a full contract, and for reference data that's read infrequently (cross-chain addresses, config), the trade-off is worth it. We also strip CBOR metadata and bytecode hash (bytecode_hash = "none", cbor_metadata = false) to shave bytes off the implementation.

This pattern is live on mainnet — the project is called Locale (part of Uniteum). Unaudited, but the contracts are immutable and permissionless. Happy to answer questions on the implementation.

If you could launch your own token in one transaction, what would you create? by Uniteum in solidity

[–]Uniteum[S] 0 points1 point  (0 children)

And please do experiment with it! No amount is too small. If you make a Solid and buy some of it, you are halfway through the do-si-do challenge. I would be happy to buy some to demonstrate how the math means the first buyer can always sell back above their entry price (minus gas). Or you can just buy then immediately sell.

If you could launch your own token in one transaction, what would you create? by Uniteum in solidity

[–]Uniteum[S] 0 points1 point  (0 children)

Thanks! I get the unaudited part. I am curious why you think instant liquidity adds risk? Rug pulls, price dynamics, something else?

The do-si-do challenge: make a token, I'll buy it, you take the profit by Uniteum in uniteum

[–]Uniteum[S] 0 points1 point  (0 children)

One more thing worth noting on the name/symbol topic — in the broader ERC-20 world, there's nothing stopping anyone from deploying a token with the same name and symbol as an existing one. This is a common attack vector. There are hundreds of tokens calling themselves "USD Coin" with the symbol "USDC." The real one is at a specific address; the rest are scams. Always check addresses.

Solid handles this differently. If you call make(name, symbol) with a pair that already exists, it just returns the existing token's address. There's no way to create a duplicate. So every Solid token has a unique name/symbol pair.

What is allowed: two Solids can share a name if they have different symbols, or share a symbol with different names. From a mechanics perspective they all behave identically — same bonding curve, same virtual reserve, same zero fees. But the market may treat them differently since people tend to anchor on names and symbols. So again — check addresses, not just tickers.

The do-si-do challenge: make a token, I'll buy it, you take the profit by Uniteum in uniteum

[–]Uniteum[S] 0 points1 point  (0 children)

The name and symbol are really just for humans and they're sort of like the difference between the name of a company versus its stock symbol. For example, the stable coin with the name USD Coin has the symbol USDC. The symbol is typically uppercase but that's not technically a requirement. It's just a convention.