FXPool support on Arbitrum

[schystz]

Description

Adds FXPoolDeployer address on Arbitrum, which should enable FXPools to be discovered on Arbitrum network

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency changes
• Code refactor / cleanup
• Documentation or wording changes
• Other

How should this be tested?

yarn codegen should generate the updated manifest for arbitrum with the FXPoolDeployer section added

Checklist:

• I have performed a self-review of my own code
• I have requested at least 1 review (If the PR is significant enough, use best judgement here)
• I have commented my code where relevant, particularly in hard-to-understand areas

dev -> master

• I have checked that all beta deployments have synced
• I have checked that the earliest block in the polygon pruned deployment is block, date/time
  • The earliest block is more than 24 hours old
• I have checked that core metrics are the same in the beta and production deployments

Merges to dev

• I have checked that the graft base is not a pruned deployment

[mendesfabio]

LGTM, but do you have any FX pool planned for Arbitrum? if so worth going ahead and adding fxAssetAggregators to assets/arbitrum.json - otherwise, we'll have to re-deploy it in the future

[schystz]

LGTM, but do you have any FX pool planned for Arbitrum? if so worth going ahead and adding fxAssetAggregators to assets/arbitrum.json - otherwise, we'll have to re-deploy it in the future

Hey @mendesfabio, thanks for the heads up! With the new FXPoolDeployer however, we no longer have to rely on fxAssetAggregators as the handler fetches the fx aggregator address dynamically and saves it to FXOracle entity. See

balancer-subgraph-v2/src/mappings/poolFactory.ts

Lines 648 to 676 in 431067f

	// For FXPoolDeployer (permissionless), fetch the aggregator address dynamically
	let poolContract = FXPool.bind(poolAddress);
	for (let i = 0; i < tokensAddresses.length; i++) {
	let tokenAddress = tokensAddresses[i];
	let assimCall = poolContract.try_assimilator(tokenAddress);
	if (assimCall.reverted) continue;
	let assimContract = Assimilator.bind(assimCall.value);
	let oracleCall = assimContract.try_oracle();
	if (oracleCall.reverted) continue;
	let oracleContract = ChainlinkPriceFeed.bind(oracleCall.value);
	let aggregatorCall = oracleContract.try_aggregator();
	if (aggregatorCall.reverted) continue;
	// Create OffchainAggregator template
	let aggregatorAddress = aggregatorCall.value;
	OffchainAggregator.create(aggregatorAddress);
	// Update FXOracle supported tokens
	let oracle = getFXOracle(aggregatorAddress);
	let tokenAddresses = oracle.tokens;
	const tokenExists = tokenAddresses.includes(tokenAddress);
	if (!tokenExists) {
	tokenAddresses.push(tokenAddress);
	}
	oracle.tokens = tokenAddresses;
	oracle.save();

On the price update part, the handler just checks FXOracle:

balancer-subgraph-v2/src/mappings/pricing.ts

Lines 385 to 395 in 431067f

	// Also check if aggregator exists from FXOracle entity (FXPoolDeployer version)
	let oracle = FXOracle.load(aggregatorAddress.toHexString());
	if (oracle) {
	for (let i = 0; i < oracle.tokens.length; i++) {
	const tokenAddress = Address.fromBytes(oracle.tokens[i]);
	const tokenExists = tokenAddressesToUpdate.includes(tokenAddress);
	if (!tokenExists) {
	tokenAddressesToUpdate.push(tokenAddress);
	}
	}
	}

So I think we don't have to worry about the fxAssetAggregators at all for Arbitrum.

[mendesfabio]

ah, that's true, sorry @schystz! we'll merge this PR today, keep you guys posted =)

[schystz]

ah, that's true, sorry @schystz! we'll merge this PR today, keep you guys posted =)

No worries at all! Glad that we both agreed :) Thank you!

[mendesfabio]

@schystz closing this PR in favor of #556 -- had to change the grafting params to speed up the syncing