I don't love that we've baked Alchemy in so deep, fwiw (though not a blocker).

The connection to the RPC URL has become dynamic with the inclusion of support for connecting to different networks. Therefore, the implemented solution, as can be seen below, is that the RPC url changes dynamically according to the connected network, following the service pattern, for example, if the connected network is Arbitrum on Sepolia, the RPC url would be 'https://arbitrum-sepolia.g.alchemy.com/v2/SERVICE-API'. Other services, as Infura, might offer various RPC urls on demand based on the connected networks, but it's expected that the pattern would change.

We can expand the possibilities of different services provided, but some sort of check should be done in this regard. If you think this should be changed, do you have any suggestions for an approach? For example, we could include an environment variable that determines the type of service—e.g., RPC_SERVICE_NAME: 'Alchemy', 'Infura', etc.—and perform validation through an enum providing different URL patterns. Or, alternatively, perhaps a more advanced validation could be done against the API pattern being passed as a parameter in the RPC API in the env file?

I also agree that I don't love how deeply entrenched Alchemy is in the code eg. alchemyName in the network definition. Down the road if we decide to switch away from Alchemy, it would be tricky to replace with some other RPC service like Infura or dRPC.

I'm not familiar with the code, so just speculating, but perhaps you could have a generic API_KEY and then an additional API_SERVICE_NAME variable and a mapping of rpc service name -> rpc config, and the configs have properties/methods to provide/adjust the required names/values/templated strings accordingly. Adding a supported service would involve adding a config entry to the mapping...?

That being said, that can probably be addressed/investigated in a separate PR.

I tend to agree that this can be better structured based on multiple possible services, so I opened the following issue to track this #790, and I'm going to address this in a separate PR.

Is this underlying calc based on the chain being used i.e was it specific to Ethereum, and now needs to be adjusted based on chain being used?

The total time required for the minting process to finalize is at least one hour, consdiering the necessary optimisticMintingDelay in TBTCVault contract time to elapse. This is not realistically aligned with how the code was originally implemented, since it was based solely on the duration of Bitcoin network confirmations.

Thus, considering that the finalizeOptimisticMint function must be called for the deposit to be finalized, it becomes difficult to precisely determine how long the entire process will take. On top of that, this extra waiting period can include an additional 15-30 minutes that may be required for bridging from L1 to L2 in the event of a cross-chain deposit. Consequently, increasing the total estimated time by 50% provides a more flexible estimate, taking into account both the new dynamics introduced by optimistic minting and the 15–30 minutes typically needed for L1–L2 bridging.

Why the rounding down instead of up?

Math.floor is used instead of Math.round to ensure that it always get round down to the nearest 30-minute block avoiding overstating the number of hours.

Do we still care about these? Is this related to legacy staking which is no more? (cc @cygnusv )

If so, might be out of scope for this PR, but we should probably remove this.

I recently caught an user in Discord requesting information to how to upgrade his Nu token to T, so I believe it might still be relevant to keep those functionalities in place for the time being.

Ah yes, the vending machine. I was really thinking with respect to staking.

Would sepolia be considered isTestnetNetwork in which case "ethereum_goerli" would be used? Is that intended?

Yes any of the Sepolia networks would return true in isTestnetNetwork function validation, this implementation follows the comment previously added about the persistance of the ethereum_goerli usage while Ledger Live currencyId hasn't been fully tested in Sepolia network.

Great documentation.

Thanks, this will definitely be useful for future maintenance, such as adding or removing networks that the app should support

I also agree that I don't love how deeply entrenched Alchemy is in the code eg. alchemyName in the network definition. Down the road if we decide to switch away from Alchemy, it would be tricky to replace with some other RPC service like Infura or dRPC.

I'm not familiar with the code, so just speculating, but perhaps you could have a generic API_KEY and then an additional API_SERVICE_NAME variable and a mapping of rpc service name -> rpc config, and the configs have properties/methods to provide/adjust the required names/values/templated strings accordingly. Adding a supported service would involve adding a config entry to the mapping...?

That being said, that can probably be addressed/investigated in a separate PR.

Was this registry always hardcoded for the dashboard or are you hardcoding it now? I believe that it is typically obtained from a published npm package - https://www.npmjs.com/package/@nucypher/nucypher-contracts for all TACo domains. Same comment for other TacoRegistry.json files (cc @manumonti , @theref who are more familiar)