Ownership, upgrade and role events
How Forensia builds a timeline of control changes on a contract, and how much history it actually covers.
#Plain languageIn plain terms
Contracts that can be changed usually announce it. When ownership moves, when the logic is upgraded, when the contract is paused, or when someone is given a privileged role, the contract writes a short public notice called an event.
Forensia collects those notices for the contract you looked up and lists them newest first. It also tells you exactly how far back it searched, because a timeline with no visible gap is easy to mistake for a complete one.
#How it worksHow it works
The lookup asks the network for logs emitted by the contract whose type matches one of eight standard administrative events. It starts at the newest block and works backwards in windows, widening each window when a request succeeds and narrowing it when a request fails.
#Technical detailThe exact rules
| Event | Address shown |
|---|---|
OwnershipTransferred(address,address) | New owner |
Upgraded(address) | New implementation |
AdminChanged(address,address) | New admin |
BeaconUpgraded(address) | New beacon |
Paused(address) and Unpaused(address) | Account that acted |
RoleGranted(bytes32,address,address) | Account granted the role |
RoleRevoked(bytes32,address,address) | Account losing the role |
The address is read from one indexed topic of the log (the first for Upgraded, BeaconUpgraded, Paused and Unpaused, the second for the rest). Log data is not decoded. When a contract emits one of these events with its addresses in the data and not in topics, the row shows no address.
Each event is matched by the Keccak-256 hash of its signature, which is the first topic of the log. Requests are eth_getLogs filtered to the contract's address and that list of topics.
| Budget | Value |
|---|---|
| Target depth | 12,000 blocks back from the newest |
| Requests | 8 |
| Total time | 8 seconds |
| Per request | 4 seconds or the time left, whichever is less |
| Rows shown | 24 newest |
- Start with a window of 64 blocks ending at the newest block, or fewer where the provider caps log queries below that.
- On success, record the logs, move the cursor back, and double the window.
- On failure, halve the window and retry. A retry spends one request. The window is never cut below the network's standard event window (18 or 24 blocks) or the provider's cap, whichever is smaller.
- Stop on the first of: target depth reached, requests spent, time spent, the source refusing even the smallest window, or reaching the first block.
The stop reason is reported with the result as one of target-window, request-budget, time-budget, source-unavailable or genesis-boundary, alongside the number of blocks actually covered. The finding is finding:administrative-events, class lead, confidence medium. It appears only when at least one matching log was captured. The covered range and stop reason are reported either way.
#LimitsWhat it does not tell you
- Some providers cap a log query at a handful of blocks. On those, eight requests cover very little history. The covered block count on the page is the number to trust.
- A contract can change control without emitting any of these events.
- Only one address per event is shown. Role identifiers and previous owners are not decoded.
- Two-step ownership transfers, timelock events and multisig events are not in the watched list.