Start here
Network
Chain IDs, RPCs, explorer, and the live contract addresses.
GIWA Sepolia#
GIWA is an OP Stack L2 with roughly 1-second blocks. Standard EVM tooling applies: Hardhat, Foundry, viem, and any wallet that can add a custom chain.
| Chain ID | 91342 |
| Native currency | ETH |
| RPC | https://sepolia-rpc.giwa.io |
| Flashblocks RPC | https://sepolia-rpc-flashblocks.giwa.io |
| Explorer | https://sepolia-explorer.giwa.io (Blockscout) |
| Indexer API | https://api.joseon.fun |
| App | https://joseon.fun, https://swap.joseon.fun |
The public RPCs are rate limited and meant for development. Anything running continuously should use its own node or a commercial provider.
Flashblocks#
The Flashblocks RPC returns a preconfirmation signal in roughly 200ms, which is what the app uses to show Flash Confirmed right after you sign. It is a UX affordance, not finality — treat it as a strong hint and wait for the real receipt before you consider a trade settled.
Live contracts (V3 stack)#
Deployed 2026-07-26. All seven are source-verified on Blockscout.
| Contract | Address |
|---|---|
| JoseonLaunchFactoryV3 | 0x87A02E73778979b86487E30304f57eaaA044BCd0 |
| JoseonSwapFactoryV3 | 0x3c892A39A0c8287592E74815E21581d6aDCcf2B5 |
| JoseonSwapRouter | 0xF347ADa4e1C0b565FC1399FB2Cb70e56B47F65C2 |
| MigrationManagerV2 | 0x51A87AB31AEC6d2fdEfD46072E3839636646d162 |
| LaunchRegistry | 0x4368d52D68b035482ba740693250281535f3C457 |
| PermanentLiquidityLocker | 0x5d2Cf817f6d403FdFc2344E37C768D7CCD3305F5 |
| WETH9 | 0xFD20F4555a526230479583449D1ce6F6C6980D8F |
Use one stack at a time. Every stack ships its own WETH and its own factory, so a V3 token has no pair on the V2 router. Mixing addresses does not revert loudly — it routes to a DEX where your token does not exist.
Retired stacks#
V1 (0x4Ec57b44…) and V2 (0x837Ff4f6…) launch factories are no longer indexed or supported by the app. Their
records live in the repo under docs/deployments/. Curves that were mid-flight on the V2 launch factory can still
graduate, because the V2 swap factory kept its creator authorisation.
Why versions instead of proxies#
A pair's bytecode is fixed when its factory deploys it, and both LaunchRegistry.launchFactory and
MigrationManager.launchFactory hold a single address. Changing pair behaviour therefore cascades:
swap factory ──▶ launch factory ──▶ migration manager ──▶ registry ──▶ lockerThat is deliberate. Nothing here is upgradeable, so a deployed launch cannot have its rules changed underneath it. The cost is that improvements ship as a new stack and the front end cuts over.
Verifying a token yourself#
Blockscout does not match freshly deployed per-launch contracts against already-verified bytecode, so a new token and its curve show as unverified until someone submits them. The repo has a script that reads constructor arguments back from the chain and submits both:
npx hardhat run --network giwaSepolia scripts/verify-launch-giwa.ts
# just one launch
JOSEON_VERIFY_TOKEN=0x… npx hardhat run --network giwaSepolia scripts/verify-launch-giwa.tsTo check a contract's status without trusting a deploy log:
curl -s https://sepolia-explorer.giwa.io/api/v2/smart-contracts/<address> \
| python3 -c "import sys,json;print(json.load(sys.stdin)['is_fully_verified'])"
Sourcify does not know chain 91342, so Hardhat's --verify exits non-zero even when Blockscout verification
succeeded. Judge by the explorer, not the exit code.