> For the complete documentation index, see [llms.txt](https://omen-protocol.gitbook.io/omen-protocol-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://omen-protocol.gitbook.io/omen-protocol-docs/omen-architecture/core-concepts.md).

# Core Concepts

Learn the key concepts behind OMEN Protocol, including token listing reviews, holder access, swap fees, and the distinction between live features and planned functionality.

This section explains the mechanisms and terminology used across OMEN Protocol. It distinguishes existing platform functionality from features that are still being developed.

### Token Listing Review

OMEN Listed is a proposed listing review process for projects that want their tokens to appear on OMEN.

Projects can submit token information for review. Submissions may be approved or rejected by the OMEN team, and only approved listings receive the OMEN Listed badge.

The badge indicates that a token has been approved for listing under the OMEN process. It does not represent a security audit, a guarantee of legitimacy, or an endorsement of the token as an investment.

Submission requirements and review procedures should be published separately once finalized.

### Holder Based Access

OMEN plans to introduce token-based access for selected platform features using $OMEN holdings.

The proposed model includes access levels with different AI usage allowances. Exact balance requirements, daily limits, eligibility checks, and activation details remain subject to implementation and official confirmation.

Until these rules are finalized and available in the platform, proposed access levels should not be considered active benefits.

### Swap Fees

OMEN Utility integrates token swaps through external trading infrastructure. A swap may involve network fees, price impact, slippage, and fees charged by the relevant service providers.

OMEN may also introduce an integration fee on eligible swaps. Any such fee should be disclosed clearly before a user confirms a transaction.

The applicable fee, supported routes, and recipient configuration must be verified against the live implementation. Users should rely on the fee details displayed for their transaction rather than assume every swap has the same cost.

### Wallet Authorization

OMEN does not take control of a user's wallet simply because it is connected to the platform.

A wallet connection enables supported wallet-related functions. Individual transactions still require authorization through the connected wallet. Users should check the destination, token, amount, and transaction details before signing.

Never share a seed phrase or private key with anyone claiming to represent OMEN.

### Live Features and Planned Features

OMEN Protocol is under active development. Some capabilities may already be available in OMEN Utility, while others remain planned.

Documentation should identify planned functionality clearly and should only describe a feature as live after it has been implemented and verified.

Roadmap items, proposed holder benefits, and future integrations are not guarantees of delivery.

### Important Distinction

A platform listing is not a security audit. AI generated analysis is not a guarantee of accuracy. Token ownership does not automatically grant benefits unless the relevant access mechanism is active.

Users should independently evaluate digital assets and understand the risks before interacting with any crypto platform.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://omen-protocol.gitbook.io/omen-protocol-docs/omen-architecture/core-concepts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
