Derived address attributes
See these facts on an entity page →
The TraceFast knowledge graph describes what an address is and what it can do, without trying to say who owns it — names are the business of the labelling layer. It is built in layers: proven facts about an address at the bottom, and derived attributes on top of them. The derived layer is the one a consumer normally wants: finished fields, already assembled from what was proven.
They arrive in the same response as everything else, under the derived:
prefix — see the address attributes method.
:::info The derived principle A derived attribute is a fold over already-proven facts, never new evidence. The projection is computed once, on our side, and served as one field: a consumer should never have to assemble "a smart account is A or B or C" out of lower-level ids, because that logic belongs with the data and is versioned with it.
The same principle decides what is derived in the first place. An umbrella
concept whose name is itself a claim — smart_account — is always a
projection. The layer below proves a specific mechanism; the umbrella is the
product-facing reading of it.
:::
How to read a derived row
Every entry in attributeDetails whose attributeId starts with derived:
carries:
| Field | Meaning |
|---|---|
attributeId | derived:<projection> |
result | always pass — the presence of the entry is the statement. Absence means "not proven", never "no" |
value | JSON: a string for the enum projections, or an array of the proven facts the umbrella was assembled from |
referenceBlock | the block at which the newest contribution to the projection was observed |
{
"attributeId": "derived:smart_account",
"result": "pass",
"value": "[\"architecture:safe_proxy_account\",\"standard:erc4337_account_observed\"]",
"referenceBlock": 21374112
}Enum projections
One classifying value per address, folded from several facts.
| Attribute | Values | What it answers |
|---|---|---|
derived:account_type | eoa · contract · smart_account · destroyed_contract · system · unknown | The primary classification of the address — the first thing most consumers need |
derived:lifecycle | live · destroyed · redeployed_live · delegated_eoa | Where the code at this address stands, including redeployment and EIP-7702 delegation |
derived:proxy_kind | storage_slot · beacon · clone · safe · eip7702 | Which proxy mechanism, when the address is a proxy |
derived:control_model | immutable · key_controlled · multisig_controlled · contract_controlled · role_key_controlled · role_multisig_controlled · role_contract_controlled · renounced | Who can act on the contract and how: a single key, a multisig, another contract, a role model — or control renounced |
derived:token_standard | erc20 · erc721 · erc1155 · erc777 · erc4626 | The leading token interface of the contract |
derived:defi_role | dex_pool · dex_factory · dex_hook · dex_pool_manager · lending_pool · lending_market · lending_position_token · lending_price_oracle · lending_rate_model · flashloan_provider · vault · vault_share | The address's role in DeFi infrastructure, in one word |
derived:upgrade_authority | key_admin · multisig_admin · contract_admin | What holds the right to upgrade an upgradeable contract |
Umbrella projections
value is the array of proven facts behind the umbrella, so a consumer can see
what it was assembled from without needing to know how each part was
proven.
| Attribute | Umbrella over |
|---|---|
derived:smart_account | The address is a smart account by any mechanism — ERC-4337, Safe, EIP-7702 delegation |
derived:account_abstraction | Participation in account-abstraction infrastructure: accounts, paymasters, entry points, singletons |
derived:signature_validator | The address can validate signatures — ERC-1271 and related mechanisms |
derived:upgradeable | The code behind the address can be replaced: a mutable implementation slot, a beacon, a delegation |
derived:token_contract | The contract is an asset — fungible, NFT, LP, vault share, lending position token |
derived:nft_features | The NFT-side interfaces it presents: metadata, enumerable, royalties, multi-token |
derived:defi_participant | Every proven DeFi role of the address at once — as opposed to defi_role, which names the leading one |
derived:controller | The address controls other contracts: owner, proxy admin, role admin, guardian |
derived:privileged_controls | Privileged surfaces exist on the contract: mint, pause, blacklist, emergency roles |
derived:privileged_action_observed | Privileged actions were observed in its history: an upgrade happened, it was paused, ownership was renounced |
derived:shared_infrastructure | The address is shared network infrastructure: precompiles, system contracts, singletons, beacons, registries |
derived:code_history_notable | A notable code history: redeployment, metamorphic code, observed upgrades, a past EIP-7702 delegation |
The pair privileged_controls / privileged_action_observed shows a
distinction that runs through the whole graph: a surface (what the code can
do) and an observation (what actually happened) are different statements,
and they are never merged into one attribute.
Guarantees
- Projections follow their facts. When any contribution changes, the projection is reassembled for that address as a whole.
- A projection never outlives its basis. If a fact behind it disappears, the projection narrows or disappears with it.
- Absence is "not proven", never "disproven". The graph states a negative
only where the negation itself was proven and has its own value — for
example
control_model = renounced.
Related pages
- Attributes of an address — the method that returns these attributes, and the full response vocabulary
- Attributes at a block — the same attributes as they stood at a past block
- Paying with x402 — how a call is paid for
- Entity Page — the same facts, read in the app
Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown