Data sources and your rights.

Depending on which tool a customer called, the categories of information that can appear about you are:

• Your name.
• A work email address associated with you. The provider represents that this is an address it found actually published; we have not independently confirmed that it is never constructed from a detected company naming pattern instead.
• Your job title, seniority, and department, including a fuller free-text version of your title when one is available.
• Your employer.
• A phone number associated with you, when a lookup surfaces one. Our tools do not distinguish a work line from a personal number, so this may be either.
• A public professional-networking profile URL (for example, a LinkedIn or social profile you have made public).
• Metadata about where your work email address has been seen associated with a public source (a URL, when, and whether that source still shows it as of our last check) — returned by an email-verification lookup, and also included as sourcing detail behind a name/email match from the other lookups. That URL is sometimes the page itself and sometimes a search-results link pointing at where our provider located it, depending on how the provider recorded the source.
• For some lookups: a derived label indicating whether we assessed you as a likely decision-maker at your employer. This is an inference generated from the public information above, not a separately-sourced fact, and can be wrong.
• A confidence score and a range of other technical signals our tools automatically generate about your specific work email address or your employer's domain — for example, a 0-100 confidence score that the address is really yours, whether our checks found it currently deliverable, whether it looks like a personal inbox versus a shared or generic one, a raw label for how the address was located, and lower-level mail-server checks (syntax, domain mail records, mailbox existence, disposable- or catch-all-address detection). This is not an exhaustive list — these are all automatically generated assessments our tools compute themselves, not separately-sourced facts, and can be wrong or become outdated. Email us if you want the complete current field list for the specific tool that returned data about you.
• For our wallet-lookup tools: on-chain activity associated with a public wallet address — balances, transaction history, token or NFT holdings, and their timestamps and transaction hashes, along with human-readable labels for on-chain contracts (for example, the name of a token contract). This is all public, on-chain data. Some regulators have treated a wallet address as personal data when it can be linked to a specific individual through other means (for example, KYC records or on-chain analytics); we have not independently assessed whether our own use creates that link.
• Also for our wallet-lookup tools, and separate from the on-chain data above: a label our provider generates naming who it assessed a wallet address — the one you looked up, or the other party to one of its transactions — to belong to (as distinct from a contract label like the token-contract example above). Like the decision-maker inference above, this is an inference our provider computes, carrying its own confidence score, not a fact recorded on the chain itself, and can be wrong.

None of the fields these tools are built to return — in their documented output — is a government identification number, a traditional financial account number (a bank or card account), or a health information field. That assurance is about identifiers like these, not about the on-chain wallet data described above: a wallet address, its balance, and its transaction history are a different kind of information, disclosed separately above, and are not covered or excluded by this sentence. Their underlying providers' raw responses are not filtered field-by-field against an exhaustive allow-list, so this is a statement about what these tools are designed and documented to return, not a guarantee about every possible byte a provider could ever send back. If that changes as more tools go live, or if we learn a provider has sent back something outside what we describe here, we will update this page.

This information is not collected from you directly. It is also not always scraped: for an address-verification lookup, the address itself is one our customer already had and typed in — only the provenance describing where it appears publicly is scraped, not the address itself. Otherwise, the third-party provider that operates the specific tool a customer called represents that it sources this information from publicly indexed web pages, public professional-networking profiles, or — for our wallet-lookup tools' on-chain facts (balances, transaction history, token or NFT holdings, and contract labels) — the public blockchain itself. The entity/counterparty-attribution labels described above are different: they are the upstream provider's own computed inference, not something read directly off the chain. None of this comes from anything private, paywalled, or access-restricted — we do not independently audit that sourcing ourselves. See the subprocessors page for how our hosting and payments subprocessors work generally, and for the specific providers it names.

Where this information originates geographically: for the category of tools that source this data from a third-party provider, that provider is incorporated in Delaware, United States, confirmed against its own public privacy policy, which also discloses separately appointed EU and UK data-protection representatives for that provider. A representative appointment like that describes the provider's own compliance posture toward the people it processes data for; it is not, on its own, a safeguard for our own use of that provider on your behalf.

Who receives it: the Omnial MCP customer who made the lookup; the third-party providers that route or run the lookup on our behalf; and our infrastructure hosting provider, which stores the run record containing it as part of operating the service. We do not otherwise share your information, except where legally required to disclose it, to protect our or someone else's rights or safety, or if the business is ever sold or merged, in which case your information would transfer with it the same way our other stored data would.

Omnial MCP is a reseller: a customer pays a fee when a lookup returns a match for you. Depending on how a given data-protection law defines the term, that payment structure may itself count as a "sale" of your information — for example, under the CCPA. Some lookups (a company-domain search) can return information about more than one person from the same organization in a single request. We have assessed internally whether that combination makes us a data broker under laws that regulate that status specifically; that assessment is documented, is not free of doubt, and does not conclude with certainty that it does not apply. We do not sell or share your information with anyone outside the specific lookup a customer already ran. If that concerns you, the Objection right below lets you ask us to stop.

We rely on what data protection law calls legitimate interest: running a paid lookup product that returns publicly available professional information, or — for our wallet-lookup tools — public on-chain activity, weighed against your rights and reasonable expectations as the person the information is about. For the professional-information lookup tools, that weighing is documented internally, and the rights below are how we act on the balance it strikes — you do not have to accept our conclusion silently, you can ask us to stop.

Two exceptions, disclosed rather than glossed over. First, the decision-maker inference described above has not yet had that same internal weighing done specifically for it. Second, for our wallet-lookup tools: the entity/counterparty-attribution labels described above — the inference our provider computes about who a wallet address belongs to, not the underlying on-chain facts like balances, transaction history, or contract labels — has likewise not yet had that same internal weighing done specifically for it. Until either has, you can ask us to stop using that inference about you specifically, the same way as anything else on this page.

Today, a run's stored output — including any information it returned about you — is kept the same way the rest of the customer's run history is kept (see the privacy policy's retention section): indefinitely, since closing a workspace does not itself delete its run history. We do not yet run an automatic deletion schedule specific to this category of information. If you ask us to delete what we hold about you (see below), we act on that request by hand rather than waiting for an automated process to catch up.

Wherever you live, we will honour the following. You do not need to cite a law at us, and we will not ask you why.

• Access: find out what we hold about you.
• Correction: have anything inaccurate fixed.
• Deletion: have what we hold about you removed from our records.
• Objection: ask us to stop processing your information for this purpose.
• Restriction: ask us to limit how we use your information while an objection or correction you raised is still being resolved.

Email pixellabsweb3@gmail.com and tell us who you are and what you are asking for. We will respond within 30 days, or sooner where a shorter legal deadline applies to your request.

Two honest limits on what we can actually do, which apply to deletion, correction, and objection alike. First, we can only act on what we hold in our own records — it does not make the underlying page or profile the information came from disappear from the public web, and a future lookup could surface the same information again from the same public source, which we would need to act on again. Second, some of the third-party providers we route tool calls through keep their own separate copy of something they processed, on their own retention schedule that we do not control — what we do reaches what we hold, not that provider's own copy. We have not yet itemized that per provider on this site; email us and we will tell you what we currently know for the specific tool involved.

If you are in the EU or UK you also have the right to complain to your data protection authority. If you are in California, we confirm we have not shared personal information for cross-context behavioural advertising, and we will not discriminate against you for exercising any right above.

If we change what we process about non-customer individuals or why, we will update this page and the effective date at the top.

Questions about any of this go to contact. See also the privacy policy and the subprocessors page.