# Introducing KOR Protocol

## What is KOR Protocol?

KOR Protocol is an onchain clearinghouse for creative assets. The protocol coordinates three functions across the lifecycle of a creative work: **verifying** origin and ownership, **routing** the work to demand-side parties, and **settling** value across the participants.

Built on Base. Stablecoin-native. Designed for a world where AI agents need to license content at machine speed.

***

## Why This Exists

AI collapsed the cost of production to near zero.

A 19-year-old in Bandung produces a track that out-mixes a major-label release. A solo creator in Lagos ships a series that out-performs a Netflix original. A bedroom DJ in Berlin builds a sound that rivals Tale of Us. A digital painter in Seoul moves more prints in a month than a Chelsea gallery moves in a year.

The tools caught up. The infrastructure didn't.

There's no trusted record of origin. Ownership lives in PDFs and email threads. Payments take 30-90 days and eat 5-10% in fees. And autonomous systems that want to license a sound for 0.3 seconds of a generated video? They can't even participate.

The creative economy runs on rails built for a different era. KOR Protocol is the upgrade.

***

## Three Engines

The protocol is organized into three engines:

```
                ┌───────────────────────────────────┐
                │                                   │
                ▼                                   │
                |   VERIFY ───► ROUTE ───► SETTLE   │
           (what is real) (where it moves) (value clears)  
                │                                   ▲
                │                                   │
                └───────── outcome data ────────────┘
                           reputation updates
```

### Verify

*What is real, who owns it, and is it clear to move?*

The Verify Engine establishes origin, ownership, and clearance state for registered assets. Before anything can be distributed, licensed, remixed, or monetized, someone needs to know where it came from.

Each asset gets a canonical on-chain identifier, an attestation graph for commercial state, and clearance derived from that graph. The token gives the asset a stable identity. The graph carries the data that changes over time—licenses, derivatives, commercial relationships.

This is the clearing function that makes assets legible enough to route downstream.

### Route

*Where does it move?*

The Route Engine moves verified assets toward demand-side parties through specialized agents. Agents have on-chain identity, declared capabilities, and reputation scores. Routing produces actions: pitches, workflows, deal-flow handoffs.

Route is in development. The current release focuses on Verify and Settle.

### Settle

*Clear value back to source.*

The Settle Engine clears value across participants when transactions close. Splits are programmatic, denominated in stablecoin, executed atomically.

Each settlement writes back to the protocol. The asset accumulates a royalty history—every license, brand deal, sync, and micropayment queryable with timestamps and counterparties.

Crypto rails aren't ideological here. They're practical. The AI era creates transactions that are too small, too global, too fast, and too programmable for SWIFT wires and 60-day net invoices. Stablecoins fix that.

***

## Why Base?

Base is Coinbase's L2. We picked it for straightforward reasons:

* **Fast**: sub-second finality
* **Cheap**: fractions of a cent per transaction
* **Secure**: inherits Ethereum's security
* **Connected**: 100M+ Coinbase users, native USDC
* **Standards**: x402, ERC-8004, and account abstraction have their deepest deployments here

When an AI agent needs to pay a creator in Jakarta and another in LA, they settle on the same rail. No FX. No correspondent banks. No waiting.

KOR is not a chain. The protocol does not run a sequencer or validator infrastructure. We pick the chain that already has the users, the liquidity, and the standards.

***

## Core Primitives

Four building blocks power the Verify and Settle engines today:

**IP Assets** Register any creative work onchain. Music, video, images, code. Origin and ownership become verifiable. Each registration creates an on-chain identifier and seeds an attestation graph with the initial ownership claim.

**Token-Bound Accounts** Every IP Asset gets its own wallet (ERC-6551). The IP itself can hold assets, receive payments, execute transactions. Not the creator's wallet—the IP's wallet. This matters for programmable royalties and autonomous licensing.

**Licensing** Attach terms directly to IP. Who can use it, under what conditions, at what price. Enforced by code, not lawyers chasing invoices.

**Royalty Distribution** When IP generates money, it splits automatically. No invoices. No net-60. The rules are set upfront and the contracts execute them. Splits are declared at registration and updated by attestation as commercial relationships evolve.

***

## Who Uses This

**Creators** who want provable authenticity, discoverability through intelligent routing, and instant payment when their work gets used.

**Labels and publishers** managing catalogs with complex rights structures who are tired of quarterly reconciliation nightmares.

**Agencies and MCNs** settling brand deals across 40 markets without the banking friction.

**Platforms** that need verified IP and native licensing.

**AI agents** that need to transact at machine speed without asking permission.

***

## Ecosystem

KOR Protocol is the infrastructure layer: registry, attestation graph, settlement contracts, licensing. The protocol is permissionless—anyone can build against it.

The following surfaces operate on the protocol today, built and operated by the KOR team:

**Korus** — Music remixing and creation. Output registers into the protocol with authorship and provenance attached at creation.

**VRSNS** — Video generation for creators. Assets register with provenance metadata and become licensable immediately.

**Pacer** — AI operating system for music. The interface where artists interact with the protocol's routing and distribution capabilities.

**Streamline** — AI operating system for creators more broadly. Extends the Pacer pattern across video, visual art, and multi-format workflows.

**Hubs** — Community engagement and monetization. Where partners, audiences, and creators connect. Settlement for subscriptions, fan tokens, and gated experiences runs through the protocol.

The protocol layer is open. You can register assets, integrate licensing, and settle through the same contracts these surfaces use.

***

## What's Next

The current release focuses on the Verify and Settle engines. The Route Engine—with specialized agents, match engine, and curation rails—is in active development.

Standards we're building toward:

| Standard | Function                        | Status |
| -------- | ------------------------------- | ------ |
| ERC-721  | Asset identifier                | Live   |
| ERC-6551 | Token-bound accounts            | Live   |
| ERC-8004 | Agent identity, reputation      | Coming |
| x402     | HTTP-native stablecoin payments | Coming |
| ERC-7683 | Cross-chain intents             | Coming |

***

## Next

* [How KOR Protocol Works](/getting-started/how-kor-protocol-works) — the technical architecture
* [Developer Onboarding](/getting-started/developer-onboarding) — get running in 5 minutes
* [SDK Reference](/sdk-reference/introduction) — full API docs


# How KOR Protocol Works

The protocol implements three engines—Verify, Route, Settle—through a layered architecture: **SDK → Backend → Blockchain**. The SDK talks to our backend, the backend signs transactions, your user's wallet submits them. Keeps blockchain complexity out of the way while preserving security guarantees.

***

## The Loop

Every operation flows through the same cycle:

![The Loop - KOR Protocol Flow](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-b6701debf64d3eedc015e72174a6b284e9bb5a35%2Fthe-loop-diagram.jpg?alt=media)

**Registration.** A creator registers an asset. The registration creates a canonical on-chain identifier, an attestation graph seeded with the initial ownership claim, and a clearance state derived from the graph.

**Routing.** Once an asset is registered and clear-to-move, it can be routed toward partners. *(Route Engine in development)*

**Settlement.** A closed match clears through the Settle layer. Splits are programmatic, denominated in stablecoin, executed atomically across participants.

**Feedback.** Each settlement writes back to the protocol. The asset accumulates royalty history—timestamps, counterparties, deal terms.

***

## Architecture

```
┌─────────────────────────────────────────────────────────────────┐
│                        YOUR APPLICATION                         │
└─────────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                         KOR SDK                                 │
│            TypeScript. Handles API calls + tx submission.       │
└─────────────────────────────────────────────────────────────────┘
                               │
                    ┌──────────┴──────────┐
                    ▼                     ▼
┌───────────────────────────┐  ┌──────────────────────────────────┐
│      KOR BACKEND          │  │         USER WALLET              │
│  Validates, encodes,      │  │  MetaMask, Coinbase, whatever.   │
│  signs tx data            │  │  Signs + pays gas.               │
└───────────────────────────┘  └──────────────────────────────────┘
                    │                     │
                    └──────────┬──────────┘
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                      BASE NETWORK                               │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                    VERIFY ENGINE                         │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │ NFT Module  │  │  IP Module  │  │Asset Module │      │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                    SETTLE ENGINE                         │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │License Module│ │Royalty Module│ │Dispute Module│     │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                  TOKEN-BOUND ACCOUNTS                    │   │
│  │                     (ERC-6551)                           │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
```

***

## Transaction Flow

Every operation follows the same two-step pattern:

**Step 1: Get signature from backend**

Your app calls the SDK. SDK hits our backend. Backend validates your API key, encodes the transaction, signs it, sends back the signature + encoded data.

**Step 2: User wallet submits**

SDK takes that payload and routes it through the user's wallet. User sees the transaction, confirms, pays gas (fractions of a cent on Base).

Why this pattern? Users stay in control of their assets. They sign every transaction. But the protocol can still validate and authorize operations server-side.

```typescript
// Register an NFT as IP
const { request } = await kor.ip.registerIp({
  nftContract: "0x...",
  tokenId: "1",
  licensors: [{ licensorAddress: "0x...", licensorPercentage: 100 }]
});

// User signs and submits
const txHash = await walletClient.writeContract(request);
```

***

## Verify Engine Modules

The Verify Engine establishes origin, ownership, and clearance state. Three modules:

### NFT Module

Creates and manages collections.

| Function               | What it does                                        |
| ---------------------- | --------------------------------------------------- |
| `createCollection`     | Deploy a new ERC-721 collection                     |
| `createIpCollection`   | Deploy a collection where mints auto-register as IP |
| `mint`                 | Mint to a collection                                |
| `mintFromIpCollection` | Mint + auto-register as IP Asset                    |

### IP Module

The core registration layer. Registers NFTs as IP and creates token-bound accounts.

| Function                   | What it does                               |
| -------------------------- | ------------------------------------------ |
| `registerIp`               | Register any NFT as an IP Asset            |
| `registerIpFromCollection` | Register with collection-level licensing   |
| `registerDerivative`       | Register work that derives from parent IP  |
| `getIpAccount`             | Get the ERC-6551 account address for an IP |

Each registration creates:

* A canonical on-chain identifier (ERC-721 token)
* An off-chain content pointer (IPFS or Arweave hash)
* Metadata describing format, creation context, and AI-provenance status

### Asset Module

Off-chain metadata and storage.

| Function           | What it does                    |
| ------------------ | ------------------------------- |
| `uploadAsset`      | Upload to decentralized storage |
| `getAssetMetadata` | Retrieve metadata               |

***

## Settle Engine Modules

The Settle Engine clears value across participants. Three modules:

### License Module

Attaches terms to IP.

| Function          | What it does                          |
| ----------------- | ------------------------------------- |
| `attachLicense`   | Attach license terms to an IP Asset   |
| `mintLicense`     | Mint a license token for usage rights |
| `getLicenseTerms` | Query terms for an IP                 |

### Royalty Module

Handles splits and distributions.

| Function              | What it does                         |
| --------------------- | ------------------------------------ |
| `setRoyaltySplit`     | Define percentages for collaborators |
| `distributeRoyalties` | Trigger distribution                 |
| `claimRoyalties`      | Claim what's owed                    |

Splits are declared at asset registration and updated as commercial relationships evolve. A track with three producers, one vocalist, a manager on 10%, and a label on 15% has those splits encoded from registration. When revenue arrives, the settlement contract distributes atomically.

### Dispute Module

For ownership disputes.

| Function         | What it does          |
| ---------------- | --------------------- |
| `raiseDispute`   | Initiate dispute      |
| `resolveDispute` | Resolve with evidence |

***

## Token-Bound Accounts (ERC-6551)

Every IP Asset registered on the protocol gets its own smart contract wallet. Not a wallet controlled by the creator—a wallet controlled by the IP itself.

```
┌─────────────────────────────────────────┐
│            NFT (IP Asset)               │
│         Contract: 0xABC...              │
│         Token ID: 42                    │
└─────────────────────────────────────────┘
                    │
                    │ ERC-6551 Registry creates
                    ▼
┌─────────────────────────────────────────┐
│      Token-Bound Account (TBA)          │
│         Address: 0xDEF...               │
│                                         │
│  → Receives royalty payments            │
│  → Holds licensing revenue              │
│  → Can own other assets                 │
│  → Controlled by NFT owner              │
└─────────────────────────────────────────┘
```

**IP can hold assets.** Revenue flows to the IP, not just the creator's wallet. Makes accounting cleaner when rights structures get complex.

**Programmable ownership.** The wallet executes transactions on behalf of the IP. Royalties split automatically. Licenses execute without manual intervention.

**Portable identity.** The IP has an onchain identity that persists across platforms. History, reputation, relationships travel with it.

When someone licenses your IP or a derivative generates revenue, payments go to the token-bound account. The NFT owner can withdraw whenever they want.

***

## Clearance State

Clearance state is a derived property of an asset's attestation graph. An asset is "clear-to-move" for a given action when the graph satisfies the conditions required for that action.

Different actions require different conditions:

* **Transient license** requires only unambiguous ownership
* **Sample license** requires unambiguous ownership plus consistency with the source's terms
* **Full transfer** requires the above plus absence of conflicting authorship claims

Downstream contracts check clearance state before acting. A settlement contract won't clear a license payment if the licensor can't be unambiguously identified.

***

## Network Details

### Base Sepolia (Testnet)

| Contract    | Address                                                       |
| ----------- | ------------------------------------------------------------- |
| NFT Module  | `0x7797A484C7a9aAa238D40476A022E5C5e3e2e0e3`                  |
| IP Module   | `0xd97fEB28aD630A3f8561a0decee0fed26842b718`                  |
| Backend API | `https://backend-production-a7215.up.railway.app/kor-sdk-api` |

Chain ID: `84532`

### Base Mainnet

Coming.

***

## What's Coming

### Route Engine

The Route Engine moves verified assets toward demand-side parties through specialized agents:

* **A\&R agents** scan signal for emerging talent matching a partner's discovery brief
* **Sync-licensing agents** match assets to brand briefs and music supervision needs
* **Partner-matching agents** route assets to specific demand-side parties

Agents will be registered with on-chain identity (ERC-8004), declared capability surfaces, and bonded reputation scores.

### Agent-Ready Payments

x402 is an open standard for HTTP-native stablecoin payments. Every registered asset will expose an x402-compatible endpoint for transient licensing and usage payments. An autonomous agent issues an HTTP request, receives a 402 response with payment requirements, executes USDC payment, and receives the resource with a verifiable receipt.

### Chain-Abstracted Settlement

Cross-chain settlement via ERC-7683 intents. A participant signs an intent ("pay me," "license this catalog"). A solver network competes to fulfill across whatever combination of chains and stablecoins produces the best execution.

***

## What You Can Build

**Creator platforms** — register user content as IP, automate royalties on remixes

**Music distribution** — manage releases as IP Assets, split royalties between artists/producers/labels automatically

**AI training marketplaces** — license IP for model training with programmable usage rights

**Digital art galleries** — verify authenticity, track provenance through derivatives

**Brand partnership platforms** — match creators with brands, settle instantly on crypto rails

***

## Next

* [Developer Onboarding](/getting-started/developer-onboarding) — set up your environment
* [SDK Reference](/sdk-reference/introduction) — full API docs
* [Key Business Flows](/reference/flow) — common patterns


# Developer Onboarding

Get running in 5 minutes.

***

## Checklist

* [ ] [Get your API key](#1-get-your-api-key)
* [ ] [Install the SDK](#2-install-the-sdk)
* [ ] [Connect to Base Sepolia](#3-connect-to-base-sepolia)
* [ ] [Register your first IP Asset](#4-register-your-first-ip-asset)

***

## 1. Get Your API Key

The SDK authenticates through API keys scoped to specific domains.

{% hint style="info" %}
**Testnet access:** Contact the KOR team for a Base Sepolia API key.
{% endhint %}

Your key looks like:

```
kor_sk_test_a1b2c3d4e5f6...
```

Don't commit it to version control.

***

## 2. Install the SDK

{% tabs %}
{% tab title="npm" %}

```bash
npm install @kor-protocol/sdk ethers
```

{% endtab %}

{% tab title="yarn" %}

```bash
yarn add @kor-protocol/sdk ethers
```

{% endtab %}

{% tab title="pnpm" %}

```bash
pnpm add @kor-protocol/sdk ethers
```

{% endtab %}
{% endtabs %}

***

## 3. Connect to Base Sepolia

```typescript
import { KorClient } from '@kor-protocol/sdk';
import { createWalletClient, http } from 'viem';
import { baseSepolia } from 'viem/chains';
import { privateKeyToAccount } from 'viem/accounts';

const kor = new KorClient({
  apiKey: process.env.KOR_API_KEY,
  network: 'base-sepolia'
});

const account = privateKeyToAccount(process.env.PRIVATE_KEY);
const walletClient = createWalletClient({
  account,
  chain: baseSepolia,
  transport: http()
});
```

### Add Base Sepolia to your wallet

| Field        | Value                          |
| ------------ | ------------------------------ |
| Network Name | Base Sepolia                   |
| RPC URL      | `https://sepolia.base.org`     |
| Chain ID     | `84532`                        |
| Currency     | ETH                            |
| Explorer     | `https://sepolia.basescan.org` |

### Get testnet ETH

1. Grab Sepolia ETH from [sepoliafaucet.com](https://sepoliafaucet.com)
2. Bridge to Base Sepolia at [bridge.base.org](https://bridge.base.org)

***

## 4. Register Your First IP Asset

Take an NFT you own and register it as an IP Asset.

```typescript
async function registerMyIP() {
  const kor = new KorClient({
    apiKey: process.env.KOR_API_KEY,
    network: 'base-sepolia'
  });

  // Get signed tx from backend
  const { request } = await kor.ip.registerIp({
    nftContract: '0xYourNftContract...',
    tokenId: '1',
    licensors: [
      {
        licensorAddress: '0xYourWallet...',
        licensorPercentage: 100
      }
    ]
  });

  // Submit through wallet
  const txHash = await walletClient.writeContract(request);
  console.log('Submitted:', txHash);

  // Wait for confirmation
  const receipt = await publicClient.waitForTransactionReceipt({ hash: txHash });
  console.log('Registered at block:', receipt.blockNumber);
}
```

What happened:

1. Backend validated your API key and signed the transaction
2. Your wallet signed and submitted (gas cost: \~$0.001 on Base)
3. NFT is now a registered IP Asset
4. ERC-6551 token-bound account deployed for that IP

***

## 5. Verify It Worked

```typescript
const ipAccount = await kor.ip.getIpAccount({
  nftContract: '0xYourNftContract...',
  tokenId: '1'
});

console.log('IP Account:', ipAccount);
// 0x... (your IP's smart contract wallet)
```

Check it on [Base Sepolia Explorer](https://sepolia.basescan.org).

***

## Common Operations

### Create an IP Collection

Collections where every mint auto-registers as IP:

```typescript
const { request } = await kor.nft.createIpCollection({
  name: 'My Catalog',
  symbol: 'CAT',
  maxSupply: 10000,
  mintPrice: '0',
  licensors: [
    { licensorAddress: '0x...', licensorPercentage: 100 }
  ]
});
```

### Mint from IP Collection

```typescript
const { request } = await kor.nft.mintFromIpCollection({
  collectionAddress: '0xYourCollection...',
  recipient: '0xRecipient...',
  tokenUri: 'ipfs://...'
});
```

### Register a Derivative

Link derivative work to parent IP:

```typescript
const { request } = await kor.ip.registerDerivative({
  nftContract: '0xDerivativeNft...',
  tokenId: '1',
  parentIpIds: ['0xParentIpAccount...'],
  licensors: [
    { licensorAddress: '0x...', licensorPercentage: 80 },
    { licensorAddress: '0x...', licensorPercentage: 20 }
  ]
});
```

***

## Next

| What you want               | Where to go                                                       |
| --------------------------- | ----------------------------------------------------------------- |
| Understand the architecture | [How KOR Protocol Works](/getting-started/how-kor-protocol-works) |
| Full API reference          | [SDK Reference](/sdk-reference/introduction)                      |
| Integration patterns        | [Key Business Flows](/reference/flow)                             |
| Contract addresses          | [Smart Contract Reference](/reference/sc)                         |

***

## Help

* **Discord:** [Join](/getting-started/developer-onboarding)
* **GitHub:** [github.com/kor-protocol](https://github.com/kor-protocol)
* **Email:** <developers@kor.xyz>


# Overview

KOR Protocol is an onchain clearinghouse for creative assets. The architecture is organized into three engines that coordinate across the lifecycle of a creative work.

***

## Three Engines

```
                ┌───────────────────────────────────┐
                │                                   │
                ▼                                   │
        VERIFY ───► ROUTE ───► SETTLE               │
    (what is real) (where it moves) (value clears)  │
                │                                   ▲
                │                                   │
                └───────── outcome data ────────────┘
                           reputation updates
```

**Verify** — establishes origin, ownership, and clearance state for a registered asset.

**Route** — moves a verified asset toward demand-side parties through specialized agents. *(In development)*

**Settle** — clears value across participants and writes commercial state back to the asset.

Each engine composes against external standards rather than reinventing infrastructure:

| Engine | Standards                                                                        |
| ------ | -------------------------------------------------------------------------------- |
| Verify | ERC-721 for asset registration, EAS-style attestation graph for commercial state |
| Route  | ERC-8004 for agent identity, A2A for messaging *(coming)*                        |
| Settle | ERC-6551 for token-bound accounts, stablecoin settlement in USDC                 |

***

## Module Organization

The protocol SDK exposes six modules, mapped to the engines:

### Verify Engine Modules

| Module           | Function                                                  |
| ---------------- | --------------------------------------------------------- |
| **NFT Module**   | Creates and manages ERC-721 collections                   |
| **IP Module**    | Registers NFTs as IP Assets, creates token-bound accounts |
| **Asset Module** | Off-chain metadata and decentralized storage              |

### Settle Engine Modules

| Module             | Function                            |
| ------------------ | ----------------------------------- |
| **License Module** | Attaches license terms to IP Assets |
| **Royalty Module** | Handles splits and distributions    |
| **Dispute Module** | Resolves ownership disputes         |

Four modules—IP, License, Royalty, and Dispute—are coordinated by the Orchestrator Architecture. This approach streamlines the system, reducing complexity and improving code organization.

***

## Component Diagram

```
┌─────────────────────────────────────────────────────────────────┐
│                        YOUR APPLICATION                         │
└─────────────────────────────────────────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                         KOR SDK                                 │
│            TypeScript. Handles API calls + tx submission.       │
└─────────────────────────────────────────────────────────────────┘
                               │
                    ┌──────────┴──────────┐
                    ▼                     ▼
┌───────────────────────────┐  ┌──────────────────────────────────┐
│      KOR BACKEND          │  │         USER WALLET              │
│  Validates, encodes,      │  │  MetaMask, Coinbase, etc.        │
│  signs tx data            │  │  Signs + pays gas.               │
└───────────────────────────┘  └──────────────────────────────────┘
                    │                     │
                    └──────────┬──────────┘
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                      BASE NETWORK                               │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                    VERIFY ENGINE                         │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │ NFT Module  │  │  IP Module  │  │Asset Module │      │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │              ROUTE ENGINE (In Development)               │   │
│  │         Agent Registry │ Match Engine │ Curation         │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                    SETTLE ENGINE                         │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │   │
│  │  │License Module│ │Royalty Module│ │Dispute Module│     │   │
│  │  └─────────────┘  └─────────────┘  └─────────────┘      │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                  TOKEN-BOUND ACCOUNTS                    │   │
│  │                     (ERC-6551 Registry)                  │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
```

***

## Data Flow

### The Loop

![The Loop - KOR Protocol Flow](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-b6701debf64d3eedc015e72174a6b284e9bb5a35%2Fthe-loop-diagram.jpg?alt=media)

1. **Registration** — A creator registers an asset. Creates a canonical on-chain identifier, an attestation graph seeded with the initial ownership claim, and a clearance state derived from the graph.
2. **Routing** — Once an asset is registered and clear-to-move, Route agents ingest signal about the asset, query the attestation graph, and route toward partners. *(In development)*
3. **Settlement** — A closed match clears through the Settle layer. Splits are programmatic, denominated in stablecoin, executed atomically.
4. **Feedback** — Each settlement writes back to the protocol. The asset accumulates royalty history with timestamps and counterparties.

### Transaction Pattern

Every SDK operation follows the same two-step pattern:

**Step 1: Backend signature** Your app calls the SDK → SDK hits backend → Backend validates API key, encodes transaction, signs it → Returns signature + encoded data

**Step 2: User submission** SDK routes payload through user's wallet → User confirms → Transaction executes on Base

This pattern keeps users in control of their assets while allowing server-side validation.

***

## Core Primitives

### IP Assets

Each registered asset has:

* A canonical on-chain identifier (ERC-721 token)
* An off-chain content pointer (IPFS or Arweave hash)
* Signed metadata describing format, creation context, and AI-provenance status

The token is the index into protocol state. Commercial state lives in the attestation graph and is queried separately by downstream contracts.

### Token-Bound Accounts (ERC-6551)

Every IP Asset gets its own smart contract wallet controlled by the IP itself:

* Receives royalty payments
* Holds licensing revenue
* Can own other assets
* Controlled by NFT owner

### Attestation Graph

The attestation graph holds signed claims about an asset:

* Sample and derivative clearance claims
* Authorship and co-creation claims
* Commercial-state claims (licenses, deals, splits)

The graph is the data structure that the rest of the protocol queries when it needs to know anything about an asset.

### Clearance State

Clearance state is derived from the attestation graph. An asset is "clear-to-move" for a given action when the graph satisfies the required conditions. Different actions require different conditions.

***

## What's Coming

### Route Engine

Specialized agents with on-chain identity (ERC-8004):

* A\&R agents for talent discovery
* Sync-licensing agents for brand matching
* Partner-matching agents for distribution

### Agent Payments

x402 for HTTP-native stablecoin payments. Assets expose payment endpoints that agents can transact with directly.

### Cross-Chain Settlement

ERC-7683 intents for chain-abstracted value transfer.

***

## Next

* [NFT Module](/architecture/modules/nft-module)
* [IP Module](/architecture/modules/ip-module)
* [License Module](/architecture/modules/license-module)
* [Royalty Module](/architecture/modules/royalty-module)


# Event Listener

The Event Listener Service is a crucial component of our architecture, designed to monitor and handle events emitted by the Kor protocol smart contracts. This service is responsible for ensuring that all relevant blockchain events are captured, processed, and stored efficiently for further analysis and use.

## High-Level Architecture

1. **Connection to RPC Providers**:
   * The Event Listener Service is connected to both Ankr and Alchemy RPC providers. These providers offer robust and reliable access to the Ethereum network, allowing our service to monitor the Kor protocol smart contracts for any events.
2. **Event Detection**:
   * When an event is emitted by a Kor protocol smart contract, the Event Listener Service detects this event in real-time. This ensures that no significant blockchain activity goes unnoticed.
3. **Message Queue Integration**:
   * Upon detecting an event, the Event Listener Service sends the event data to AWS SQS (Simple Queue Service). This decouples the event detection from the processing, allowing for more scalable and fault-tolerant operations.
4. **Consumer Service**:
   * The Consumer Service picks up the events from the AWS SQS queue. It decodes the event data and processes it to extract relevant information.
5. **Data Storage**:
   * The processed event data is then transmitted to a database where it is stored in an indexed form. This allows for efficient querying and retrieval of event data for various applications.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-787d2af5bda653b8f05b7e6998e76fe472549cb3%2Fkor-Event-Listener.drawio%20\(1\).png?alt=media)

## Workflow

1. **Listening for Events**:
   * The Event Listener Service continuously listens to the Kor protocol smart contracts through the connected RPC providers (Ankr and Alchemy).
2. **Event Emission**:
   * When an event is emitted, it is immediately detected by the Event Listener Service.
3. **Queuing the Event**:
   * The event data is packaged and sent to AWS SQS, ensuring it is queued for further processing.
4. **Consuming the Event**:
   * The Consumer Service retrieves the event from the AWS SQS queue, decodes it, and processes the data.
5. **Storing the Event**:
   * The processed data is stored in a database with appropriate indexing, facilitating efficient data management and retrieval.


# Modules


# NFT Module

NFT Module consists of set of Smart Contracts which allows users and Artists to -

* Create their own NFT Collection.
* Mint NFT from the Collection and further use it to register as an IP.
* Create their own IP Collection.
* Directly mint an IP from IP Collection.
* Mint NFT from protocol NFT Contract.

It consists of contracts developed using various ERCs and modifying them accordingly.

![NFT Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-1a335089698f9a6e402c6da98377a6aac4880e93%2Fnft-module.png?alt=media)

## Mint IP from the Collection

Minting IP from a Artist IP Collection mints an IP Asset directly to user without having a need to register the NFT and attaching License Terms to it. SDK mints an NFT from the Artist Collection, registers it as an IP, attaches the License terms to it as defined in the Collection IP Account and mints this IP Asset to user. This process is done in one go.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-0e93e1693c4d7751be03113a10410fdca5c9a9e5%2Fmint-ip-from-artist-collection.png?alt=media)


# IP Module

This module is responsible for the IP Asset related functionalities, like -

* Registering an NFT as IP Asset
* Creating KOR ERC-6551 Token Bound Accounts for the NFTs
* Managing Roles for an IP
* Registering derivatives
* Query of IPs
* Registering a collection as an IP

![IP Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-566eeca47e263b0a45ac00b96fbfa890e575e288%2FIP-module-arch.png?alt=media)

## Register IP Asset

The process of registering an NFT as a IP Asset includes configuring the roles for the IP Asset, for example Licensee Role, Copyright Role etc. then the IP Registry created an Token Bound Account for the NFT which is referred as IP Account.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-91bcce0a10b0c74e5d83d7c44f9d06913b1f05a1%2Fregister-ip-asset.png?alt=media)

## Register Collection as IP

To register a whole NFT collection as an IP user have to configure the Roles for the IP first, then sdk mints an NFT to the creator. This NFT represents the collection. Then sdk creates a KOR Token Bound Account (Modified ERC-6551) for the collection, which is referred as Collection Account.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-758aac042031f2c98972ad31be79f971e532a01a%2Fregister-collection-as-ip.png?alt=media)


# License Module

#### License Module

This module is responsible for managing the Licensing of the IP, it provides functionalities like -

* Attaching the License Terms to an IP Asset.
* Attaching the License Terms to an IP Collection.
* Minting an License Token for derivative creation.
* Registering new License Terms.
* Minting License Terms NFT.
* Deploying Royalty Vaults and Royalty Token through Royalty Module.
* Uploading License Term PDF to IPFS.

![License Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-b2e93e7c138a8ab7be83cab07c0d039cec6e7444%2Flicense-arch.png?alt=media)

#### Attach License To IP

While attaching the License terms to the IP Asset, sdk first checks the role of the user which is attaching the license for the validation check. The License Registry takes the entered License Term ID and attaches it to the IP Account and Mints a new License Terms NFT into the IP Account. The pdf of License Terms is generated and uploaded to the IPFS. When License Terms are attached to the IP Account, a call to Royalty Module is made through License Registry to deploy Royalty Vault and Royalty Token for that IP Asset.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-38b43c596c5730ee7437630f031a7fafe9f3ec7b%2Fattach-license-to-IP.png?alt=media)

#### Attach License Terms to Collection

While attaching the License terms to the IP Collection, sdk first checks the role of the user which is attaching the license for the validation check. The License Registry takes the entered License Term ID and attaches it to the Collection Account and Mints a new License Terms NFT into the Collection Account. The pdf of License Terms is generated and uploaded to the IPFS. When License Terms are attached to the Collection Account, a call to Royalty Module is made through License Registry to deploy Royalty Vault and Royalty Token for that IP Colelction.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-578be6ce11d51c9ba999d264fa4ce88579ad84ba%2Fattach-license-to-collection.png?alt=media)


# Royalty Module

Royalty Module handles all the Royalty related tasks for an IP, like-

* Paying Royalties
* Claiming Royalties
* Deploying Royalty Tokens and Royalty Vaults through factory contracts.
* Royalty calculation
* Royalty Distribution
* License Fees Management

![Royalty Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-4280901f2c1ac717d79ea33996b7391f30b20e96%2Froyalty-arch.png?alt=media)

## Mint License Token

To mint License Token of an IP Asset, sdk first checks if there is any dispute over that IP Asset, then checks for the Royalty Policy/Terms is there is any License Mint Fees applicaple then user has to pay the License Mint Fees and it is transferred to the Royalty Vault of the IP. On successful transaction, the License Token is minted to the user.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-7ec62cec40bf62bf6cfee1248f60efb2eee6da1a%2Fmint-license-token.png?alt=media)

## Pay License Mint Fees

License Mint Fees is defined in the License Terms attached to an IP. The License Mint Fees is collected by Royalty Module into the Royalty Vault of an IP Asset.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-13ae7caff2412955e9b53fe416fbd674fae206c7%2Fpay-license-fees.png?alt=media)

## Pay Royalty

Users can pay Royalties to an IP. The Royalty module checks for the dispute, then transfers the Royalty to the Royalty Vault of the IP.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-b6ce3e20469f265544d4fac5a4a8bac08eb91aca%2Fpay-royalty.png?alt=media)

## Claim Royalty

To claim Royalty, SDK first checks for the Roles of the caller. Then it fetches the Royalty share based on the Royalty Tokens holding of the Recipient and transfers the Royalty from the Royalty Vault.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-64fbc72d651e7386339f73fe87c20ce944e06432%2Fclaim-royalty.png?alt=media)


# Asset Module

Asset Module consists of the components which are used to-

* Upload the Asset to IPFS
* Generate the ISCC Codes for the Assets
* Create Metadata for IP or Collection
* Upload the Metadata to IPFS
* ISCC codes comparison

It uses the International Standard Content Code library to generate the ISCC code for the Asset and uses Pinata to upload the data to the IPFS.

![Asset Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-d22b16ea9867147e3241bf7200d88b6d90f980c9%2Fasset-module.png?alt=media)

## Upload Asset

As user uploads the Asset, sdk generates the ISCC code for it and uploads the Asset to the IPFS, returns the URI of the Asset.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-691e420539a4d35e29444c98c938d18c34b7f3ff%2Fupload-asset1.png?alt=media)

## Upload Collection

When an Artist uploads the collection folder, the sdk generates ISCC for each Asset present in the collection and uploads the Assets to the IPFS, returns the URIs of the Assets.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-7bc6b49a482c87714b5ef7c9cc87023198724615%2Fupload-collection1.png?alt=media)

## Upload Metadata

Metadata is generated using the ISCC code and Asset URI returned while uploading the Asset and other Metadata Fields, then the Metadata is uploaded to IPFS and user gets the Metadata URI in return.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-a6170d3f7e3649270ca70564ab154bbad6aaa50d%2Fupload-metadata.png?alt=media)


# Dispute Module

Dispute Module handles the dispute related tasks in the protocol, like -

* Raising Disputes
* Resolving Disputes
* Getting Dispute details
* Atbitrator management
* Dispute fee management

![Dispute Module](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-dabe8bbe0e3a6adae81754069e10b27578658aba%2Fdispute-arch.png?alt=media)

## Raise Dispute

To raise an Dispute, user has to enter Dispute Evidence Link, Dispute Tier and stake the tokens based on the Tier. The tokens are transferred to an Escrow Fee contract and Arbitrator fee is paid. After successful transaction the IP is marked as Disputed and stopped from creating further derivatives until the dispute is resolved.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-30fd048ec5bf971a4308d5a581ce378974d494aa%2Fraise-dispute.png?alt=media)

## Resolve Dispute

Disputes can only be resolved by the Arbitrator. The Arbitrator reviews the Dispute Evidence and based on that checks the validation of the dispute. If the Dispute is valid, the remaining staked tokens are transferd back to the Disputant and the IP is Locked. If the dispute is not valid then remaining tokens are used by the platform and IP is untagged from Disputed.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-7aa0cd0e18f6c807eae0abf0efed85689a88fef2%2Fresolve-dispute.png?alt=media)


# Introduction

This document explains how to set up and use Kor Protocol TypeScript SDK. The SDK allows users to interact with Kor Protocol smart contract securely using an API key issued upon subscription.


# Installation

## Prerequisites

To follow this tutorial, ensure you have Node version 20 or later and npm version 8 or higher installed in your environment. You can download the latest LTS (Long Term Support) version from the [Node.js official website](https://nodejs.org/).

If you need to upgrade Node to version 20 or higher, we recommend using nvm (Node Version Manager). To upgrade npm to the latest version, use the following command:

```sh
npm install -g nvm
```

## Create a Node Project

First, create a folder named `kor-ts-example`:

```sh
mkdir kor-ts-example
```

Navigate into the folder and run `npm init` to initialize the project:

```sh
cd kor-ts-example/
npm init
```

You can accept all default values by pressing the enter key when prompted for package name, version, description, etc. After running the command, you will see a file named `package.json` in the directory.

## Install the Dependencies

While in the `kor-ts-example` folder, install the Kor Protocol SDK node package,

You can use any of the following package managers to install the dependencies:

```sh
npm install --save @kor-protocol/core-sdk 
```

or

```sh
pnpm add @kor-protocol/core-sdk 
```

or

```sh
yarn add @kor-protocol/core-sdk 
```


# Initialization

To initialize the SDK, you need to provide your API key and the RPC URL of the blockchain network.

```markdown
import { Kor } from '@kor-protocol/core-sdk';

const apiKey = 'your-api-key';
const rpcUrl = 'https://your-rpc-url';
const backendUrl = 'https://kor-backend-url';

const sdk = new Kor(rpcUrl, apiKey, backendUrl);
```

1. **API Key**: This is your unique key to authenticate your requests to the Kor Protocol backend.
2. **RPC URL**: This is the URL of the blockchain network you are connecting to. It could be the URL of a public or private Ethereum node.
3. **Backend URL**: This is the URL of the Kor Protocol backend services.

By using the Kor class from the `@kor-protocol/core-sdk package`, you can create an instance of the SDK by providing these parameters. This instance will allow you to interact with the Kor Protocol APIs and perform various blockchain operations.


# Client Methods

The SDK includes various clients, each with specific methods. Below are examples for the Metadata Client, NFT Client, Asset Client, and License Client.


# NFT Client

## NFTClient

The `NFTClient` allows you to perform various operations related to NFTs.

### Methods

* createCollection
* mintFromCollection
* mintIpFromArtistCollection
* mintFromKorProtocol
* updateMetadata

### createCollection

The `createCollection` function is used to create a standard collection or an Artist collection.

| Method             | Type                                                                       |
| ------------------ | -------------------------------------------------------------------------- |
| `createCollection` | `(request: createCollectionRequest) => Promise< createCollectionResponse>` |

* **Parameters**:
  * `request.name`: The name associated with the collection.
  * `request.symbol`: The symbol representing the collection.
  * `request.bannerImage`: The banner image for collection.
  * `request.type`: Collection type (Artist || Standard).
  * `request.mintingFee`: The fee associated while minting NFT.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.contractAddress` - The collection contract address.

### mintFromCollection

The `mintFromCollection` function is used to mint an NFT from standard collection.

| Method               | Type                                                                           |
| -------------------- | ------------------------------------------------------------------------------ |
| `mintFromCollection` | `(request: mintFromCollectionRequest) => Promise< mintFromCollectionResponse>` |

* **Parameters**:
  * `request.contractAddress`: The address of the collection contract.
  * `request.uri`: The URI associated with the NFT.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.tokenId` - The token id of an NFT.

### mintIpFromArtistCollection

The `mintIpFromArtistCollection` function is used to mint an NFT from artist collection.

| Method                       | Type                                                                                           |
| ---------------------------- | ---------------------------------------------------------------------------------------------- |
| `mintIpFromArtistCollection` | `(request: mintIpFromArtistCollectionRequest) => Promise< mintIpFromArtistCollectionResponse>` |

* **Parameters**:
  * `request.contractAddress`: The address of the collection contract.
  * `request.mintingFee`: The amount to be paid for minting fee.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.tokenId` - The token id of an NFT.
  * `response.ipId` - The Ip Id of an asset.

### mintFromKorProtocol

The `mintFromKorProtocol` function is used to mint an NFT from Kor protocol collection.

| Method                | Type                                                                             |
| --------------------- | -------------------------------------------------------------------------------- |
| `mintFromKorProtocol` | `(request: mintFromKorProtocolRequest) => Promise< mintFromKorProtocolResponse>` |

* **Parameters**:
  * `request.uri`: The URI associated with the NFT.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.tokenId` - The token id of an NFT.
  * `request.chainId`: The identifier for the blockchain network in the request.

### updateMetadata

The `updateMetadata` function is used to update metadata of already minted NFT.

| Method           | Type                                                                   |
| ---------------- | ---------------------------------------------------------------------- |
| `updateMetadata` | `(request: updateMetadataRequest) => Promise< updateMetadataResponse>` |

* **Parameters**:
  * `request.uri`: The new URI associated with the NFT.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.


# IP Client

## IPClient

The `IPClient` provides functionality for managing intellectual property (IP) assets. The `IPClient` simplifies the management of IP assets, making it easier to create, retrieve, and list them as needed.

### Methods

* registerIp
* registerDerivative
* mintAndRegisterIp
* registerIpAndAttachLicense
* getIpAsset

### registerIp

Register an NFT as an Intellectual Property Asset

| Method       | Type                                                          |
| ------------ | ------------------------------------------------------------- |
| `registerIp` | `(request: registerIpRequest) => Promise<registerIpResponse>` |

* **Parameters**:
  * `request.nftContractAddress`: The address of the NFT Contract address.
  * `request.tokenId`: The token id of the NFT.
  * `request.signature`: Data signature.
  * `request.deadline`: The deadline for the signature in milliseconds.
  * `request.licenseeRoles[]`: An address array specifying the roles assigned to licensees
  * `request.copyrightRoles[]`: An address array detailing the roles related to copyrights.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.ipId` - The ipId of the newly registered Ip Asset.

### registerDerivative

Register an derivative of an Ip Asset

| Method               | Type                                                                          |
| -------------------- | ----------------------------------------------------------------------------- |
| `registerDerivative` | `(request: registerDerivativeRequest) => Promise<registerDerivativeResponse>` |

* **Parameters**:
  * `request.parentIpId`: The identifier for the parent intellectual property (IP) in the request
  * `request.signature`: Data signature.
  * `request.deadline`: The deadline for the signature in milliseconds.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.ipId` - The Ip Id of the newly registered Ip Asset.

### mintAndRegisterIp

Mint an NFT and regsiter it as an Intellectual Property Asset

| Method              | Type                                                                        |
| ------------------- | --------------------------------------------------------------------------- |
| `mintAndRegisterIp` | `(request: mintAndRegisterIpRequest) => Promise<mintAndRegisterIpResponse>` |

* **Parameters**:
  * `request.nftContractAddress`: The address of the NFT Contract address.
  * `request.signature`: Data signature.
  * `request.deadline`: The deadline for the signature in milliseconds.
  * `request.licenseeRoles[]`: An address array specifying the roles assigned to licensees
  * `request.copyrightRoles[]`: An address array detailing the roles related to copyrights.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.ipId` - The Ip Id of the newly registered Ip Asset.
  * `response.tokenId` - The tokenId of the issued NFT.

### registerIpAndAttachLicense

Register an Ip and attach a license to it.

| Method                       | Type                                                                                          |
| ---------------------------- | --------------------------------------------------------------------------------------------- |
| `registerIpAndAttachLicense` | `(request: registerIpAndAttachLicenseRequest) => Promise<registerIpAndAttachLicenseResponse>` |

* **Parameters**:
  * `request.nftContractAddress`: The address of the NFT Contract address.
  * `request.tokenId`: The token id of the NFT.
  * `request.licenseTermId`: The term id of the license.
  * `request.signature`: Data signature.
  * `request.deadline`: The deadline for the signature in milliseconds.
  * `request.licenseeRoles[]`: An address array specifying the roles assigned to licensees
  * `request.copyrightRoles[]`: An address array detailing the roles related to copyrights.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.ipId` - The Ip Id of the newly registered Ip Asset.

### getIpAsset

Get details of a registered Ip.

| Method       | Type                                                          |
| ------------ | ------------------------------------------------------------- |
| `getIpAsset` | `(request: getIpAssetRequest) => Promise<getIpAssetResponse>` |

* **Parameters**:
  * `response.ipId` - The Ip Id of the registered Ip Asset.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.license` - The license details.
    * `response.license.id` - The license Id.
    * `response.license.termId` - The identifier for the license term.
    * `response.license.templateAddress` - The address of the license template.
    * `response.license.ipfsUri` - The IPFS URI for the license document.
  * `response.royalty` - The royalty information.
    * `response.royalty.vaultAddress` - The address of the royalty vault.
    * `response.royalty.royaltyTokenAddress` - The address of the royalty token.
  * `response.dispute` - The dispute details.
    * `response.dispute.disputed`- Indicates if there is a dispute.
    * `response.dispute.tag` - The tag associated with the dispute.
    * `response.dispute.disputeCount` - The number of disputes.
    * `response.dispute.locked` - Indicates if the dispute is locked.


# License Client

## LicenseClient

The `LicenseClient` is used to register and manage licenses.

### Methods

* attachLicenseToCollection
* attachLicenseTermsToIp
* registerLicenseTerms
* mintLicenseToken

### attachLicenseToCollection

The `attachLicenseToCollection` function is used to associate a license with a specific collection of intellectual property (IP) assets.

| Method                      | Type                                                                                         |
| --------------------------- | -------------------------------------------------------------------------------------------- |
| `attachLicenseToCollection` | `(request: attachLicenseToCollectionRequest) => Promise< attachLicenseToCollectionResponse>` |

* **Parameters**:
  * `request.collectionIpId`: The collection Ip Id.
  * `request.licenseTermId`: The identifier for the specific license term in the request.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.

### attachLicenseTermsToIp

The `attachLicenseTermsToIp` function is used to associate a license with a specific Ip asset.

| Method                   | Type                                                                                   |
| ------------------------ | -------------------------------------------------------------------------------------- |
| `attachLicenseTermsToIp` | `(request: attachLicenseTermsToIpRequest) => Promise< attachLicenseTermsToIpResponse>` |

* **Parameters**:
  * `request.ipId`: The identifier for the Ip.
  * `request.licenseTermId`: The identifier for the license term.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.

### registerLicenseTerms

The `registerLicenseTerms` function is used to register a new license terms.

| Method                 | Type                                                                               |
| ---------------------- | ---------------------------------------------------------------------------------- |
| `registerLicenseTerms` | `(request: registerLicenseTermsRequest) => Promise< registerLicenseTermsResponse>` |

* **Parameters**:
  * `request.licenseTerm`: The new license term.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.termId` - The term id for newly registed term

### mintLicenseToken

The `mintLicenseToken` function is used to mint a license token that can be used for creating derivatives.

| Method             | Type                                                                       |
| ------------------ | -------------------------------------------------------------------------- |
| `mintLicenseToken` | `(request: mintLicenseTokenRequest) => Promise< mintLicenseTokenResponse>` |

* **Parameters**:
  * `request.licenseId`: - The identifier for the specific license in the request.
  * `request.recipient`: - The recipient's information for the request.
  * `request.amount`: - The amount specified in the request.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.


# Royalty Client

## RoyaltyClient

The `RoyaltyClient` is used to distribute and manage royalty payouts.

### Methods

* mintRoyaltyToken
* claimRoyalty
* payRoyalty
* payLicenseRoyaltyFee

### mintRoyaltyToken

Mint royalty token to recipient address.

| Method             | Type                                                                      |
| ------------------ | ------------------------------------------------------------------------- |
| `mintRoyaltyToken` | `(request: mintRoyaltyTokenRequest) => Promise<mintRoyaltyTokenResponse>` |

* **Parameters**:
  * `response.recipient` - The recipient address.
  * `response.amount` - Amount of token to mint.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txHash` - The transaction hash.

### claimRoyalty

Royalty token holders can claim their royalties proportionate to their share of tokens held.

| Method         | Type                                                              |
| -------------- | ----------------------------------------------------------------- |
| `claimRoyalty` | `(request: claimRoyaltyRequest) => Promise<claimRoyaltyResponse>` |

* **Parameters**:
  * `response.recipient` - The recipient address.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txHash` - The transaction hash.

### payRoyalty

The payRoyalty function disburses royalties to token holders based on their ownership share.

| Method       | Type                                                          |
| ------------ | ------------------------------------------------------------- |
| `payRoyalty` | `(request: payRoyaltyRequest) => Promise<payRoyaltyResponse>` |

* **Parameters**:
  * `response.ipId` - The Ip asset Id for which royalties are to be paid.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txHash` - The transaction hash.

### payLicenseRoyaltyFee

The payLicenseRoyaltyFee function is designed to mint a license token by paying the necessary license fee.

| Method                 | Type                                                                              |
| ---------------------- | --------------------------------------------------------------------------------- |
| `payLicenseRoyaltyFee` | `(request: payLicenseRoyaltyFeeRequest) => Promise<payLicenseRoyaltyFeeResponse>` |

* **Parameters**:
  * `response.ipId` - The Ip asset Id for which license fee to be paid.
  * `response.licenseId` - License Id.
  * `response.amount` - Amount to be paid.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txHash` - The transaction hash.


# Asset Client

## AssetClient

The `AssetClient` allows you to perform various operations related to asset metadata.

Using the `AssetClient` simplifies the process of managing and storing asset metadata for your projects.

### Methods

* uploadAsset
* uploadAssetFolder
* uploadMetadata
* uploadMetadataFolder
* generateISCC
* checkISCCSimilarity

### uploadAsset

Upload an asset to IPFS and return the CID.

| Method        | Type                                                            |
| ------------- | --------------------------------------------------------------- |
| `uploadAsset` | `(request: UploadAssetRequest) => Promise<UploadAssetResponse>` |

**Parameters**

* `request.data`: The data to be uploaded to IPFS.

**Returns**

* `response.uri`: The URI of the uploaded data.

### uploadAssetFolder

Upload an asset folder to IPFS and return the base CID.

| Method              | Type                                                                        |
| ------------------- | --------------------------------------------------------------------------- |
| `uploadAssetFolder` | `(request: UploadAssetFolderRequest) => Promise<UploadAssetFolderResponse>` |

**Parameters**

* `request.data`: The data to be uploaded to IPFS.

**Returns**

* `response.baseUri`: The Base URI of the uploaded data.

### uploadMetadata

Upload metadata to IPFS and return the CID.

| Method           | Type                                                                  |
| ---------------- | --------------------------------------------------------------------- |
| `uploadMetadata` | `(request: UploadMetadataRequest) => Promise<UploadMetadataResponse>` |

* **Parameters**:
  * `request.data` - The actual metadata content.
  * `request.name` - The name of the metadata.
  * `request.symbol` - The symbol of the metadata.
  * `request.description` - The description of the metadata.
  * `request.attributes` - An array of attributes, where each attribute is an object with `trait_type` and `value` properties.
* **Returns**:
  * `response.metadataURI` - The URI (e.g., IPFS URI) where the metadata is stored.

### uploadMetadataFolder

Upload an metadata folder to IPFS and return the base CID.

| Method                 | Type                                                                              |
| ---------------------- | --------------------------------------------------------------------------------- |
| `uploadMetadataFolder` | `(request: uploadMetadataFolderRequest) => Promise<uploadMetadataFolderResponse>` |

**Parameters**

* `request.data`: The data to be uploaded to IPFS.

**Returns**

* `response.baseUri`: The Base URI of the uploaded data.

### generateISCC

Generate the ISCC of the content.

| Method         | Type                                                              |
| -------------- | ----------------------------------------------------------------- |
| `generateISCC` | `(request: generateISCCRequest) => Promise<generateISCCResponse>` |

* **Parameters**:
  * `request.data` - The actual content.
* **Returns**:
  * `response.code` - The ISCC code of content.

### checkISCCSimilarity

Check Similarity between two ISCC Code

| Method                | Type                                                                            |
| --------------------- | ------------------------------------------------------------------------------- |
| `checkISCCSimilarity` | `(request: checkISCCSimilarityRequest) => Promise<checkISCCSimilarityResponse>` |

* **Parameters**:
  * `request.ISCC1` - First ISCC Code.
  * `request.ISCC2` - Second ISCC Code
* **Returns**:
  * `response.percentage` - Similarity percentage of two ISCC code.


# Dispute Client

## DisputeClient

The `DisputesClient` can be used to raise, cancel, and resolve disputes.

### Methods

* raiseDispute
* cancelDispute
* resolveDispute
* checkDispute

### raiseDispute

Raises a dispute on a given IpId

| Method         | Type                                                              |
| -------------- | ----------------------------------------------------------------- |
| `raiseDispute` | `(request: raiseDisputeRequest) => Promise<raiseDisputeResponse>` |

* **Parameters**:
  * `request.ipId`: Ip Id for the disputed asset.
  * `request.evidenceLink`: External evidence link.
  * `request.tag`: Dispute type tag.
  * `request.tier`: Tier type of dispute.
  * `request.amount`: Amount required to pay for raising the dispute.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.
  * `response.disputeID` - Dispute Id.

### cancelDispute

Cancel a dispute on a given Ip Id.

| Method          | Type                                                                |
| --------------- | ------------------------------------------------------------------- |
| `cancelDispute` | `(request: cancelDisputeRequest) => Promise<cancelDisputeResponse>` |

* **Parameters**:
  * `request.disputeId`: Dispute Id.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.

### resolveDispute

Resolve a dispute on a given Ip Id

| Method           | Type                                                                  |
| ---------------- | --------------------------------------------------------------------- |
| `resolveDispute` | `(request: resolveDisputeRequest) => Promise<resolveDisputeResponse>` |

* **Parameters**:
  * `request.disputeId`: Dispute Id.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.txhash` - The transaction hash.

### checkDispute

Check dispute status on a given Ip Id

| Method         | Type                                                              |
| -------------- | ----------------------------------------------------------------- |
| `checkDispute` | `(request: checkDisputeRequest) => Promise<checkDisputeResponse>` |

* **Parameters**:
  * `request.disputeId`: Dispute Id.
  * `request.chainId`: The identifier for the blockchain network in the request.
* **Returns**:
  * `response.status` - Status of dispute on a given Ip Id.


# Key Business Flows

## User Flows

### Register IP and attach License

This flow shows how an NFT is Registered as an IP Asset and how a License Term is attached to it.

![Register IP and attach License](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-19a2619152b4f51368629c93c17362b7d0b61512%2Fregister-IP-attach-license.png?alt=media)

### Create and register a collection as IP

This flow represents how an Artist can create their own collection and set the License terms to Collection level.

![Create and register a collection as IP](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-e0b5ad160542d9e80bd381d1fa91a8595cd3c318%2FCreate-and-register-collection.png?alt=media)

### Mint IP from artist IP collection

This flow shows how a user can directly mint an IP Asset from artist by paying IP Minting fees(if Applicable).

![Mint IP from artist IP collection](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-c6394b1bf9e9db8ea461c13dc22add0672ea3808%2FMint-IP-from-Collection.png?alt=media)

### Mint License Token and register derivative

This flow shows how a user can mint a License Token of an IP and use it to create derivatives

![Mint License Token and register derivative](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-2755f5e8d4abcc95faa5337603b83d6a5dd9c051%2FMint%20License-Token-and-register-Derivative.png?alt=media)

### Pay royalty and claim royalty

This flow shows the process of paying royalty to an IP and claiming the Royalties from the IP Vault based on royalty token holdings.

![Pay royalty and claim royalty](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-0730728476dc3acbb5f4f04d1c851f3c9e01c950%2FPay-Royalty-and-claim-royalty.png?alt=media)

### Raise dispute and resolve dispute

This user flow shoes the process of raising dispute over an IP and process of resolving it.

![Raise dispute and resolve dispute](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-6d6df182d63ee420f695b52e62e76d124a611164%2FRaise-Dispute-and-Resolve-Dispute.png?alt=media)


# Key Terminologies

## Protocol Architecture

**Verify Engine**

The first of three protocol engines. Establishes origin, ownership, and clearance state for registered assets. Comprises the NFT Module, IP Module, and Asset Module.

**Route Engine**

The second protocol engine. Moves verified assets toward demand-side parties through specialized agents. Agents have on-chain identity, declared capabilities, and reputation scores. *(In development)*

**Settle Engine**

The third protocol engine. Clears value across participants when transactions close. Handles programmable splits, stablecoin settlement, and royalty distribution. Comprises the License Module, Royalty Module, and Dispute Module.

**Clearinghouse**

A system that coordinates verification, routing, and settlement for creative assets. KOR Protocol functions as an onchain clearinghouse.

***

## Core Primitives

**Attestation Graph**

The data structure that holds signed claims about a registered asset. The graph is queried by downstream contracts to determine clearance state. Contains sample clearance claims, authorship claims, AI provenance claims, and commercial-state claims.

**Clearance State**

A derived property of the attestation graph indicating whether an asset is clear to move for a given action. Different actions (transient license, sample license, full transfer) require different conditions to be satisfied.

**Clearing Function**

A protocol action that verifies, routes, or settles value. The three engines together implement the protocol's clearing functions.

**Commercial State**

The set of attestations describing licenses, deals, splits, and royalty obligations against an asset. Lives in the attestation graph, not on the token itself.

**Programmable Split**

A contract-encoded distribution of revenue across the parties to an asset. Declared at registration and updated by attestation as commercial relationships evolve.

**Royalty Memory**

The historical record of settlements against an asset. Every license, brand deal, sync, and micropayment is queryable with timestamps and counterparties.

***

## Standards

**ERC-721**

A widely recognized Ethereum token standard for creating non-fungible tokens (NFTs). Used by KOR for asset registration—each registered asset has a canonical on-chain identifier as an ERC-721 token.

**ERC-6551 (Token-Bound Accounts)**

A standard that allows NFTs to have associated accounts or wallets. Every IP Asset registered on KOR gets its own smart contract wallet that can hold assets, receive payments, and execute transactions.

**KOR ERC-6551**

A modified version of ERC-6551 that supports additional functionalities for the protocol, such as attaching licenses.

**ERC-8004**

A standard for AI agent identity, reputation, and validation. Defines three on-chain registries. KOR's Route Engine uses ERC-8004 for agent registration. *(Coming)*

**x402**

An open standard for HTTP-native stablecoin payments. Assets expose x402-compatible endpoints for transient licensing and usage payments. *(Coming)*

**ERC-7683**

A cross-chain intents standard for chain-abstracted settlement. Allows participants to sign intents that solver networks fulfill across multiple chains. *(Coming)*

**EAS (Ethereum Attestation Service)**

A style of attestation used for the protocol's claim graph. Attestations are signed claims backed by various trust mechanisms.

**C2PA**

A standard for AI provenance signatures. Where a creating model has signed output in C2PA-compatible format, the model's signature serves as the attestation.

***

## Assets and Identity

**IP Asset**

A registered creative work with a canonical on-chain identifier, off-chain content pointer, and signed metadata. The registration is the index into protocol state.

**IP Account**

A digital account associated with intellectual property, used to manage and track ownership and usage of IP assets. Created via ERC-6551 when an asset is registered.

**Collection IP Account**

A digital account associated with an intellectual property collection, used to mint new IPs with predefined licensing terms attached.

**Asset URI**

A Uniform Resource Identifier used to uniquely identify and access digital assets. Typically points to metadata or the digital file on IPFS or Arweave.

**KOR ID**

The identity layer of the protocol. Authenticates users via SIWE (Sign-In with Ethereum) and issues permanent identifiers. Also functions as an OAuth 2.0 / OpenID Connect provider. *(Coming)*

***

## Agents and Routing

**Route Agent**

A specialized agent registered with on-chain identity that moves assets toward demand-side parties. Types include A\&R agents, sync-licensing agents, and partner-matching agents. *(Coming)*

**Agent Registry**

The on-chain registry where Route agents are registered with declared capability surfaces and bonded reputation scores. Built on ERC-8004. *(Coming)*

**Match Engine**

The system that produces ranked matches between registered assets and demand-side parties. Combines latent-space embeddings, learned ranking on historical outcomes, and reputation weighting. *(Coming)*

**Curation Rails**

A mechanism where humans and agents bond tokens behind explicit calls about talent, matches, or briefs. Successful calls earn from clearing fees. *(Coming)*

***

## Settlement

**Staked Attestation**

A claim against an asset's attestation graph backed by bonded tokens, subject to slashing if proven false.

**Stablecoin Settlement**

All protocol settlement is stablecoin-denominated, primarily in USDC. Provides practical rails for transactions that are too small, global, fast, or programmable for traditional banking.

**Mint Fees**

Charges associated with creating or issuing NFTs or other digital tokens on a blockchain. Covers transaction fees and network charges.

***

## Storage and Metadata

**IPFS (InterPlanetary File System)**

A decentralized file storage system using a peer-to-peer network. KOR uses IPFS for off-chain content pointers.

**Arweave**

A permanent decentralized storage network. Alternative to IPFS for off-chain content storage.

**Metadata**

Information that provides details about other data. For digital assets, includes title, author, date created, format, creation context, and AI-provenance status.

**ISCC (International Standard Content Code)**

A standard for uniquely identifying and managing digital content across different platforms and systems.

***

## Ecosystem

**KOR Protocol**

An onchain clearinghouse for creative assets. Coordinates three functions: verifying origin and ownership, routing to demand-side parties, and settling value across participants.

**Korus**

A music remixing and creation tool. Output flows into the Verify Engine through asset registration with authorship and AI-provenance attestations.

**VRSNS**

Viral video generation for creators. Short-form video output is registered into the protocol with provenance metadata.

**Pacer**

An AI operating system for music. The interface where artists interact with the protocol's routing and distribution capabilities.

**Streamline**

An AI operating system for creators. Extends the Pacer pattern across video, visual art, and multi-format workflows.

**Hubs**

Community engagement and monetization. Where partners, audiences, and creators connect. Settlement venue for subscriptions, fan tokens, and gated experiences.

***

## Disputes

**Arbitrator**

A neutral third party appointed to resolve disputes between parties. Used for high-value disputes that require human arbitration beyond bonded resolution.

**Dispute Resolution**

The process of resolving contested claims. The protocol uses bonded counter-claim mechanisms where parties stake tokens behind their positions.


# Smart Contract Reference

### NFT Module

| Contract                       | Base Sepolia | Base Sepolia |
| ------------------------------ | ------------ | ------------ |
| `Protocol Collection Contract` | `-`          | `-`          |
| `Collection Facory Contract`   | `-`          | `-`          |

### IP Module

| Contract                        | Base Sepolia | ------- |
| ------------------------------- | ------------ | ------- |
| `IP Registry Contract`          | `-`          | `-`     |
| `KOR-ERC6551 registry contract` | `-`          | `-`     |
| `KOR-ERC6551 Account Contract`  | `-`          | `-`     |
| `Collection owner NFT contract` | `-`          | `-`     |

### Licensing Module

| Contract                    | Base Sepolia | ------- |
| --------------------------- | ------------ | ------- |
| `License Registry Contract` | `-`          | `-`     |
| `License Policy contract`   | `-`          | `-`     |
| `PIL Template contract`     | `-`          | `-`     |
| `License Token Contract`    | `-`          | `-`     |

### Royalty Module

| Contract                  | Base Sepolia | ------- |
| ------------------------- | ------------ | ------- |
| `Royalty Module contract` | `-`          | `-`     |
| `Royalty Policy Contract` | `-`          | `-`     |
| `Royalty Vault Factory`   | `-`          | `-`     |
| `Royalty Vault Contract`  | `-`          | `-`     |
| `Royalty Token Factory`   | `-`          | `-`     |
| `Royalty Token Contract`  | `-`          | `-`     |

### Dispute Module

| Contract                     | Base Sepolia | ------- |
| ---------------------------- | ------------ | ------- |
| `Dispute Module Contract`    | `-`          | `-`     |
| `Arbitrator Policy Contract` | `-`          | `-`     |
| `Escrow Fees contract`       | `-`          | `-`     |


# Deployment

Following is the proposed AWS deployment architecture for Development and Production deployment along with costing -

## Development and QA Architecture

![Dev & QA Architecture](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-79ee6685bd01be2a3e069fec89ab2f9af360f2e4%2Fdev-qa-arch.png?alt=media)

### Development and QA Pricing

![DEV & QA Pricing](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-8c65be54b7a242a3bfb588b3de1d6cf6ca54e41e%2Fdev-qa-price.png?alt=media)

## Production Arhitecture

![Production Architecture](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-3166d356df18ac127d1f66e723a74fec4837d8df%2Fprod-arch.png?alt=media)

## Production Pricing

![Produciton Pricing](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-0828f30e5d6389c9505358a2bf236ca52c781a3e%2Fprod-pricing.png?alt=media)


# About KOR SDK

The **KOR SDK** (Software Development Kit) is a toolkit designed to facilitate the development of applications that involve Intellactual Property Rights on blockchain. Here’s a detailed introduction to what the KOR SDK typically offers and its key components:

## **Key Features of KOR SDK**

1. **APIs and Libraries**:
   * **APIs**: The KOR SDK provides a set of application programming interfaces (APIs) that enable developers to interact with the KOR blockchain. These APIs can include functionalities for creating and managing digital assets, executing transactions, and querying blockchain data.
   * **Libraries**: Pre-built libraries included in the SDK help simplify common tasks, such as cryptographic operations, data serialization, and communication with the blockchain.
2. **Integration Tools**:
   * **Smart Contract Templates**: The SDK often includes templates and tools for developing and deploying smart contracts on the KOR blockchain, making it easier for developers to create decentralized applications (dApps).
   * **SDK Integration**: Provides mechanisms to integrate with KOR’s infrastructure, allowing users to manage their tokens and IP Assets seamlessly.
3. **Development Environment**:
   * **Development Frameworks**: The SDK may offer support for various development frameworks and environments, helping developers to build, test, and deploy applications efficiently.
   * **Testing Tools**: Includes testing environments and simulators to allow developers to test their applications in a controlled setting before deploying them to the live blockchain.
4. **Documentation and Support**:
   * **Comprehensive Documentation**: The SDK typically comes with detailed documentation that guides developers through the setup process, usage of APIs, and best practices for integrating with the platform.
   * **Community and Support**: Access to community forums, technical support, and resources to assist developers in troubleshooting issues and improving their applications.
5. **Security Features**:
   * **Encryption and Authentication**: Built-in security features to ensure secure transactions, data integrity, and user authentication.
   * **Compliance**: Tools and guidelines to help developers ensure their applications comply with relevant standards and regulations.

![](https://3190671787-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FT3uZ1rqVjUC342sSJsDq%2Fuploads%2Fgit-blob-968c809cf7df74e06bdd6db65ddf3e8b6e15efc9%2Fkor-architecture.drawio.png?alt=media)

## **Benefits of Using KOR SDK**

* **Streamlined Development**: Simplifies the process of building applications that interact with the blockchain, reducing development time and effort.
* **Enhanced Functionality**: Provides access to advanced blockchain features, enabling developers to leverage the full capabilities of the KOR platform.
* **Improved Integration**: Facilitates seamless integration with existing systems and applications, improving interoperability and user experience.

## **Use Cases**

* **Decentralized Applications (dApps)**: Developers can use the KOR SDK to build and deploy dApps that utilize KOR protocol for various purposes like music platform, art platform etc.
* **Enterprise Solutions**: Businesses can integrate KOR protocol features into their existing systems to enhance security, transparency, and efficiency in IP operations.
* **Blockchain Services**: Service providers can use the SDK to create tools and platforms that offer blockchain-based solutions to their clients.