Thinking this might be different. I've been curious what the BLE packet structure might look like. Looks like there's 16 bytes of unique id needed for the "Rolling Proximity Identifier" in the spec. Typically iBeacon would have 16 bytes of unchanging UUID, and 4 bytes that can change: https://support.kontakt.io/hc/en-gb/articles/201492492-iBeac....

Could probably flip it to be a 4 byte prefix (to identify this packet for contact tracing), followed by 16 bytes of the Rolling Proximity Identifier, but not sure if the underlying hardware (the BLE chips) can do low-power matching on a pattern like that. Something only Apple and Google could make work, so this is exciting.

(Or, it could be iBeacon to wake, then making a connection to fetch the Rolling Proximity Identifier. Though, in my experience, not requiring a connection will be more reliable in practice, especially for Android.)