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

# Marketplace

The data structure representing a marketplace is defined as follows:

```rust
#[account]
pub struct Marketplace {
    pub authority: Pubkey,
    pub permission_config: PermissionConfig,
    pub fees_config: FeesConfig,
    pub rewards_config: RewardsConfig,
    pub token_config: TokenConfig,
    pub bumps: MarketplaceBumps,
}
```

The **`Marketplace`** struct contains the following components:

* **`authority`**: The authorized entity that can modify this account data.
* **`permission_config`**: Configuration for marketplace permissions, allowing flexibility in defining marketplace rules.
* **`fees_config`**: Configuration for marketplace transaction fees.
* **`rewards_config`**: Configuration for reward systems associated with sales.
* **`token_config`**: Configuration for transaction indexing system works.
* **`bumps`**: Bump seed parameters used for deterministic address derivation.

### **Permission Configuration**

The **`PermissionConfig`** struct allows the marketplace to define various permissions:

```rust
pub struct PermissionConfig {
    pub access_mint: Pubkey,
    pub permissionless: bool,
}
```

* **`access_mint`**: Specifies the token required for sellers to create products on the marketplace when **`permissionless`** is set to **`false`**.
* **`permissionless`**: A boolean flag that, when set to **`true`**, allows anyone to sell on the marketplace without token restrictions.

### **Fees Configuration**

The **`FeesConfig`** struct enables the marketplace to manage transaction fees:

```rust
pub struct FeesConfig {
    pub discount_mint: Pubkey,
    pub fee: u16,
    pub fee_reduction: u16,
    pub fee_payer: FeePayer,
}
```

* **`discount_mint`**: Marketplaces can set a specific mint token that reduces seller fees when received as payment.
* **`fee`**: The transaction fee percentage levied by the marketplace, expressed as a whole number.
* **`fee_reduction`**: The percentage reduction applied to fees if the seller chooses to receive payment in a specific token.
* **`fee_payer`**: An enum determining who pays the transaction fees - either the **`Buyer`** or the **`Seller`**.

### **Fee Payer Enum**

The **`FeePayer`** enum represents who pays the transaction fees:

```rust
pub enum FeePayer {
    Buyer,
    Seller,
}
```

* **`Buyer`**: The buyer pays the transaction fees.
* **`Seller`**: The seller pays the transaction fees.

### **Rewards Configuration**

The **`RewardsConfig`** struct manages reward configurations for sales:

```rust
pub struct RewardsConfig {
    pub reward_mint: Pubkey,
    pub bounty_vaults: Vec<Pubkey>,
    pub seller_reward: u16,
    pub buyer_reward: u16,
    pub rewards_enabled: bool,
}
```

* **`reward_mint`**: If set, the marketplace provides rewards only when payment is made with this specific mint token.
* **`bounty_vaults`**: A list of vaults controlled by the marketplace PDA for storing reward tokens during the promotional period.
* **`seller_reward`**: The transaction volume percentage that the seller receives as a reward on a sale.
* **`buyer_reward`**: The transaction volume percentage that the buyer receives as a reward on a sale.
* **`rewards_enabled`**: A boolean flag enabling or disabling the reward system.

### **Token Configuration**

The **`RewardsConfig`** struct manages reward configurations for sales:

```rust
pub struct TokenConfig {
    pub use_cnfts: boolean,
    pub deliver_token: boolean,
    pub transferable: boolean,
    pub chain_counter: boolean,
}
```

* **`use_cnfts`:** This flag determines whether cNFTs are employed for proof of payment and indexing within the marketplace. When enabled, sellers initiate a tree structure, and buyers receive a cNFT as evidence of their transaction, achieved through the `init_product_tree` and `register_buy_cnft` processes.
* **`deliver_token`:** This setting controls the nature of payment proof that buyers receive. When set to true, buyers are issued a fungible token upon purchase. Alternatively, when set to false, a payment account is established to function as a simple counter, keeping track of the number of units bought, achieved through the `init_product` and `register_buy_token` processes.
* **`transferable`:** This flag governs the transferability of the fungible token received as payment. Enabling this feature allows users to sell or trade the token, enhancing its liquidity and potential for secondary market transactions. TokenProgram2022 allows to create Non Transferable tokens.
* **`chain_counter`:** When activated, this configuration results in the creation of a payment account. This account serves as an indexing mechanism for all transactions within the marketplace. Initiation of this account involves establishing a counter that tallies the occurrences of user purchases for a specific product. This approach is designed to be more cost-effective compared to using an individual token for each transaction.

### **Marketplace Bumps**

The **`MarketplaceBumps`** struct represents the bump seed parameters used for deterministic address derivation:

```rust
pub struct MarketplaceBumps {
    pub bump: u8,
    pub vault_bumps: Vec<u8>,
    pub access_mint_bump: u8,
}
```


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://brick-protocol.gitbook.io/docs/fundamentals/solana-program/state/marketplace.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
