Yes. In the current dual-role BLE exercises, every T-Beam starts as both:

- a BLE **peripheral/server**, advertising the Reticulum BLE service
- a BLE **central/client**, scanning for peers

The tie-breaker is the BLE MAC address string.

In [TBeamSupremeBleInterface.cpp](/usr/local/src/microreticulum/microReticulumTbeam/exercises/305_microReticulum_ble_file_transfer/src/TBeamSupremeBleInterface.cpp:293):

```cpp
return strcmp(_local_address.c_str(), peer_address.c_str()) < 0;
```

So the unit with the **lower BLE MAC address** initiates the BLE connection as the **client/central**. The unit with the higher BLE MAC stays available as the **server/peripheral**.

Sorted from lowest to highest priority by your list:

```text
1. GUY  48:ca:43:5a:40:e0
2. ED   48:ca:43:5a:90:d0
3. CY   48:ca:43:5a:91:44
4. DAN  48:ca:43:5a:93:a0
5. FLO  48:ca:43:5b:8c:74
6. BOB  48:ca:43:5b:93:dc
7. AMY  48:ca:43:5b:bf:68
```

Meaning:

```text
GUY will initiate BLE connections to everyone.
AMY will never initiate against this set; everyone else has lower priority and will connect to AMY.
BOB initiates to AMY, but stays server for GUY/ED/CY/DAN/FLO.
FLO initiates to BOB and AMY, but stays server for GUY/ED/CY/DAN.
```

There is also a second, similar tie-breaker for the Reticulum Link itself in [main.cpp](/usr/local/src/microreticulum/microReticulumTbeam/exercises/305_microReticulum_ble_file_transfer/src/main.cpp:88):

```cpp
return strcmp(node_label.c_str(), label.c_str()) < 0;
```

That compares the `Node-...` labels. In practice those labels are derived from the ESP MAC, so the same "lower identity initiates" idea is used again after the BLE connection exists.