Fix fetching custom network file

[vladimirvolek]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
blockfrost-platform-docs	Ready	Preview, Comment	Jun 18, 2026 11:42am
blockfrost-platform-docs-next	Ready	Preview, Comment	Jun 18, 2026 11:42am

[cloudflare-workers-and-pages]

Deploying blockfrost-platform with    Cloudflare Pages

Latest commit:	b82dbb0
Status:	✅  Deploy successful!
Preview URL:	https://335711bb.blockfrost-platform.pages.dev
Branch Preview URL:	https://fix-custom-network.blockfrost-platform.pages.dev

View logs

[Copilot]

Pull request overview

This PR fixes --custom-genesis-config so that a user-supplied genesis file is parsed during config construction, merged into a registry, and consistently used across the server, API handlers, and Hydra integration.

Changes:

• Load and merge custom genesis into Config up front (and set Network::Custom when provided), so the registry is authoritative everywhere.
• Update network-magic/genesis consumers (server node pool, epochs parameters, Hydra) to use the merged registry rather than the built-in lookup.
• Add unit tests covering config loading (JSON/TOML), epoch-length resolution, and the ledger genesis endpoint for custom vs built-in networks.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
crates/platform/src/server.rs	Use config.genesis for network magic and store merged registry in app state.
crates/platform/src/main.rs	Pass merged genesis into Hydra controller spawn.
crates/platform/src/hydra_client/mod.rs	Thread genesis through Hydra controller/state instead of using built-in genesis lookup.
crates/platform/src/genesis.rs	Refactor registry traits/impls to work over slices; add mutable registry trait.
crates/platform/src/epochs.rs	Make epoch parsing depend on the provided genesis registry; add tests for custom genesis.
crates/platform/src/config.rs	Parse custom genesis during config build, store merged registry, and add config-level tests.
crates/platform/src/api/ledger/genesis.rs	Add tests verifying the endpoint serves custom genesis when network is custom.
crates/platform/src/api/epochs/number/parameters.rs	Pass merged registry into EpochData::from_path.
crates/integration_tests/src/platform/mod.rs	Initialize Config with built-in genesis registry for integration test harness.
CHANGELOG.md	Document the fix for --custom-genesis-config.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[michalrus]

Something happened to the commit message of 9103223 😅:

[michalrus]

BTW, after this work, do you have any thoughts about sync progress:

blockfrost-platform/crates/node/src/sync_progress.rs

Lines 24 to 35 in b82dbb0

	// FIXME: this is debatable, because it won’t work for custom networks; we should rather
	// get this information by calling `Ouroboros.Consensus.HardFork.History.Qry.slotToWallclock`
	// like both cardano-cli (through cardano-api) and Ogmios do, but it’s not implemented
	// in pallas_network yet.
	let wellknown_genesis = wellknown::GenesisValues::from_magic(
	network_magic,
	)
	.ok_or_else(|| {
	BlockfrostError::internal_server_error(format!(
	"Only well-known networks are supported (unsupported network magic: {network_magic})"
	))
	})?;

[michalrus]

I also found this – so according to us, no stake address is valid on any custom network:

blockfrost-platform/crates/platform/src/addresses.rs

Lines 74 to 87 in b82dbb0

	pub fn is_stake_address_valid(input: &str, network: &Network) -> Result<bool, BlockfrostError> {
	let (hrp, _) = bech32::decode(input).map_err(|_| BlockfrostError::invalid_stake_address())?;
	let prefix_str = match hrp.as_str() {
	"stake" => Ok("stake"),
	"stake_test" => Ok("stake_test"),
	_ => Err(BlockfrostError::invalid_stake_address()),
	}?;
	match network {
	Network::Mainnet if prefix_str == "stake" => Ok(true),
	Network::Preprod | Network::Preview if prefix_str == "stake_test" => Ok(true),
	_ => Ok(false),
	}
	}

[vladimirvolek]

I also found this – so according to us, no stake address is valid on any custom network:

blockfrost-platform/crates/platform/src/addresses.rs

Lines 74 to 87 in b82dbb0

	pub fn is_stake_address_valid(input: &str, network: &Network) -> Result<bool, BlockfrostError> {
	let (hrp, _) = bech32::decode(input).map_err(|_| BlockfrostError::invalid_stake_address())?;
	let prefix_str = match hrp.as_str() {
	"stake" => Ok("stake"),
	"stake_test" => Ok("stake_test"),
	_ => Err(BlockfrostError::invalid_stake_address()),
	}?;
	match network {
	Network::Mainnet if prefix_str == "stake" => Ok(true),
	Network::Preprod | Network::Preview if prefix_str == "stake_test" => Ok(true),
	_ => Ok(false),
	}
	}

wow very good catch!

[michalrus]

A couple more comments:

[michalrus]

Maybe let's also check:

• active_slots_coefficient is an f64 between (0,1]
• max_lovelace_supply is a positive integer

[michalrus]

Maybe we should also reject magic numbers that shadow existing and well-known networks? So that user's GenesisRegistryMut::add with a well-known number doesn't break searching networks by magic… OTOH, one run of blockfrost-platform is bound to a specific network, so maybe it doesn’t matter that much. Like when would it matter?

[michalrus]

Maybe let's also check:

OTOH… The user wouldn't be able to run a cardano-node otherwise 🤔 I don’t know, your call

[michalrus]

Now pub type GenesisExtension above appears unused:

blockfrost-platform/crates/platform/src/genesis.rs

Line 6 in b82dbb0

pub type GenesisExtension = Extension<Arc<Vec<(Network, GenesisResponse)>>>;

[michalrus]

Okay, so now this is redundant:

blockfrost-platform/crates/platform/src/server/state.rs

Lines 8 to 13 in b82dbb0

	#[derive(Clone)]
	pub struct AppState {
	pub config: Arc<Config>,
	pub genesis: Arc<Vec<(Network, GenesisResponse)>>,
	pub data_node: Option<DataNode>,
	}

Maybe let's have all handlers reference a single source of truth: the new state.config.genesis (the line I'm commenting this on).

Removing that previous one will also surface places that are still using it (if any).