Peter Broadhurst

> A better approach would be to store the TX Hash in FireFly Core that is returned when submitting a transaction to the connector! This specific item needs to be...

Super, thanks @EnriqueL8 and @ryjones

Concrete proposal - which has other benefits: - [x] For FFTM based connectors (EVMConnect) we do the work to ensure FireFly Core and query the latest checkpoint for a listener...

The listener endpoint on FFTM already has the checkpoint information embedded, so it doesn't look like changes would be needed to the FFTM or EVMConnect codebases for Core to be...

This code confirms existence of _custom_ listeners. Per the comment it's not specific to the migration scenario: https://github.com/hyperledger/firefly/blob/16aec0b55471c2950e2d95ff90972ca0455c369d/internal/contracts/manager.go#L156-L161 This calls down to `ethereum` specific code, which gets the subscription in...

Reading through https://github.com/hyperledger/firefly/pull/1388 and the code, it seems like the original event streams are just left and ignored. However, they are not referred to in any way currently. So implementing...

For MultiParty networks (where used) the FireFly batch pin contract follows the same pattern, and there's even less code change as the namespace was included in the listener name already...

The thing that distinguishes multi-party `BatchPin` events from all other events in the `blockchainevents` table, is the lack of a `listener_id`.

For Tokens, there is a strong leaning to using either `0` or a specific block number in the code. When a user doesn't specify a block number, it goes to...

@EnriqueL8 @awrichar - I have submitted PR https://github.com/hyperledger/firefly/pull/1534 Open conversations I'd like your view on this week: - This only addresses the `newest`/`latest` case, it does **not** address the inefficiency...