Skip to content

aip-3: add content id and burn ip #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ja7ad merged 1 commit into from
Oct 14, 2025
Merged

aip-3: add content id and burn ip #6

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
148 changes: 126 additions & 22 deletions AIPs/aip-3.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ like Git, providing linear versioning with clear ownership transitions. This
familiar paradigm reduces complexity for both implementers and users while
ensuring efficient validation by network participants.

![Linear chain Workflow](../assets/aip-3/chain.png)
![Linear chain Workflow](../assets/aip-3/chain.jpg)

## Specification

Expand All @@ -95,28 +95,68 @@ Currently, transactions in Aerium support the following payload types:

#### New IP Registry Payload Types

This AIP proposes the addition of three new payload types for intellectual property management:
This AIP proposes the addition of four new payload types for intellectual property management:

- **IP Register Payload** (PayloadType: `7`) - Initial intellectual property registration
- **IP Mint Payload** (PayloadType: `7`) - Initial intellectual property registration
- **IP Update Payload** (PayloadType: `8`) - Content or metadata modification while preserving ownership
- **IP Transfer Payload** (PayloadType: `9`) - Ownership transfer to a new address
- **IP Burn Payload** (PayloadType: `10`) - Permanent destruction of IP ownership

This approach provides **zero ambiguity**, **compile-time type safety**, and
**optimal payload sizes** while maintaining **perfect alignment** with Aerium's
existing architecture patterns.

### Content ID System

The IP Registry introduces a **Content ID** system that provides stable, permanent identification
for intellectual property assets across their entire lifecycle.

**Content ID Generation**:

$$
ContentID = BLAKE2b-256(InitialContentHash || Owner || BlockNumber)
$$

Where:

- `InitialContentHash`: BLAKE2b-256 hash of original file content
- `Owner`: Address of initial owner (21 bytes)
- `BlockNumber`: Block number of mint transaction (lock time) (8 bytes, big-endian)

**Content ID Properties**:

- **Permanent**: Never changes throughout IP lifecycle
- **Unique**: Cryptographically guaranteed uniqueness
- **Deterministic**: Can be reproduced given mint transaction data

### Version Control Semantics

The IP Registry implements **semantic version control** where version numbers have
clear, specific meaning:

**Version Increment Rules**:

- **MINT**: Always version 0 (initial registration)
- **UPDATE**: Version increments by 1 (content or metadata changed)
- **TRANSFER**: **Version unchanged** (ownership transfer only)
- **BURN**: Version increments by 1 (final state change)

**Rationale**: This approach follows industry standards where version numbers reflect
content changes, not ownership changes. Similar to Git commits (content changes)
vs. repository ownership transfers (no new commit), or patent numbers (constant)
vs. patent ownership (transferable).

### Payload Size Analysis

| Operation | Fixed Fields | Optional Metadata | Total Range |
|-----------|-------------|-------------------|-------------|
| **IP Register** | 153 bytes | 0-372 bytes | 153-525 bytes |
| **IP Update** | 185 bytes | 0-372 bytes | 185-557 bytes |
| **IP Transfer** | 218 bytes | 0-372 bytes | 218-590 bytes |
| **IP Mint** | 185 bytes | 0-372 bytes | 185-557 bytes |
| **IP Update** | 217 bytes | 0-372 bytes | 217-589 bytes |
| **IP Transfer** | 250 bytes | 0-372 bytes | 250-622 bytes |
| **IP Burn** | 221 bytes | 0-100 bytes | 221-321 bytes |

@gemini-code-assist gemini-code-assist Bot Oct 14, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The Payload Size Analysis for IP Burn appears to be incorrect. The fixed fields defined in the IP Burn Payload structure (ContentID 32B, Version 4B, PreviousHash 32B, Signature 64B) sum to 132 bytes, not 221 bytes. The optional BurnReason is 100 bytes. The row should be corrected to reflect this.

Note: If the Owner field (21 bytes) is added as suggested in another comment, the fixed size would become 153 bytes.

Suggested change
| **IP Burn** | 221 bytes | 0-100 bytes | 221-321 bytes |
| **IP Burn** | 132 bytes | 0-100 bytes | 132-232 bytes |


## Payload Structures

### Common Fields

All IP Registry operations share the following metadata fields for selective privacy control:

| Field | Type | Size | Description | Required |
Expand All @@ -131,7 +171,7 @@ All IP Registry operations share the following metadata fields for selective pri
- `*1`: Optional metadata field - can be omitted for privacy control
- `*2`: Optional public link field - can be omitted to maintain content location privacy

#### On‑chain Optional Metadata Layout (372 bytes)
### On‑chain Optional Metadata Layout (372 bytes)

- Fixed slots in order: Title (100 bytes), Size (8 bytes, uint64 big‑endian),
ContentType (64 bytes), PublicLink (200 bytes).
Expand All @@ -150,39 +190,44 @@ The `PublicLink` field supports both centralized and decentralized storage:
- **IPFS Custom Gateway**: `https://gateway.pinata.cloud/ipfs/QmXXXXX...` (80+ characters)
- **Standard HTTP/HTTPS**: Custom URLs for traditional hosting

### 1. IP Register Payload (PayloadType: `7`)
### 1. IP Mint Payload (PayloadType: `7`)

**Purpose**: Initial registration of intellectual property
**Purpose**: Initial registration of intellectual property with permanent Content ID assignment

**Payload Structure**:

| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| Owner | `Address` | 21 Bytes | Current owner address | ✅ |
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier (generated deterministically) | ✅ |
| Owner | `Address` | 21 Bytes | Initial owner address | ✅ |
| ContentHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of file content | ✅ |
| MetadataHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of serialized metadata | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (must be 1) | ✅ |

@gemini-code-assist gemini-code-assist Bot Oct 14, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

There's a contradiction regarding the initial version number. The Version Control Semantics section on line 139 specifies that MINT is always version 0, but this line states it must be 1. For consistency, it should be 0.

Suggested change
| Version | `uint32` | 4 Bytes | Sequential version number (must be 1) | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (must be 0) | ✅ |

| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed `ProofHash` | ✅ |
| *Optional Metadata* | *Various* | *372 Bytes* | `Title`, `Size`, `ContentType`, `PublicLink` | *1, *2 |
| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed ProofHash | ✅ |
| *Optional Metadata* | *Various* | *372 Bytes* | Title, Size, ContentType, PublicLink | *1, *2 |

**Validation Rules:**

- `Version` MUST equal `1`

@gemini-code-assist gemini-code-assist Bot Oct 14, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This validation rule contradicts the Version Control Semantics on line 139, which states that MINT is always version 0. To align with the semantics, this rule should enforce version 0.

Suggested change
- `Version` MUST equal `1`
- `Version` MUST equal `0`

- `ContentHash` MUST be unique (not previously registered)
- `ContentID` MUST be unique (not previously registered)
- `ContentID` MUST be calculated correctly from initial content and owner
- `Owner` becomes initial IP owner

**ProofHash Calculation**:

$$ProofHash_{REGISTER} = H(ContentHash \parallel MetadataHash \parallel Version)$$
$$
ProofHash_{MINT} = H(ContentID \parallel ContentHash \parallel MetadataHash \parallel Version)
$$

### 2. IP Update Payload (PayloadType: `8`)

**Purpose**: Content or metadata modification while preserving ownership
**Purpose**: Content or metadata modification while preserving ownership and Content ID

**Payload Structure**:

| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier (unchanged from mint) | ✅ |
| Owner | `Address` | 21 Bytes | Current owner address | ✅ |
| ContentHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of file content | ✅ |
| MetadataHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of serialized metadata | ✅ |
Expand All @@ -193,43 +238,102 @@ $$ProofHash_{REGISTER} = H(ContentHash \parallel MetadataHash \parallel Version)

**Validation Rules:**

- `ContentID` MUST match existing IP state
- `Version` MUST equal `CurrentState.Version + 1`
- `Owner` MUST equal current owner in state
- `PreviousHash` MUST equal `CurrentState.LastTransactionHash`
- `ContentHash` MAY change (content update) or remain same (metadata-only update)
- IP MUST NOT be in BURNED status

**ProofHash Calculation**:

$$ProofHash_{UPDATE} = H(ContentHash \parallel MetadataHash \parallel Version \parallel PreviousHash)$$
$$
ProofHash_{UPDATE} = H(ContentID \parallel ContentHash \parallel MetadataHash \parallel Version \parallel PreviousHash)
$$

### 3. IP Transfer Payload (PayloadType: `9`)

**Purpose**: Ownership transfer to a new address
**Purpose**: Ownership transfer to a new address while maintaining Content ID and version

**Payload Structure**:

| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier (unchanged from mint) | ✅ |
| Owner | `Address` | 21 Bytes | Current owner address | ✅ |
| ContentHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of file content | ✅ |
| MetadataHash | `Hash` | 32 Bytes | BLAKE2b-256 hash of serialized metadata | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (previous + 1) | ✅ |
| Version | `uint32` | 4 Bytes | **Current version number (unchanged)** | ✅ |
| PreviousHash | `Hash` | 32 Bytes | Hash of previous IP transaction | ✅ |
| NewOwnerKey | `Bytes` | 33 Bytes | Compressed public key of new owner | ✅ |
| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed ProofHash | ✅ |
| *Optional Metadata* | *Various* | *372 Bytes* | Title, Size, ContentType, PublicLink | *1, *2 |

**Validation Rules:**

- `Version` MUST equal `CurrentState.Version + 1`
- `ContentID` MUST match existing IP state
- `Version` MUST equal `CurrentState.Version` (**NO increment**)
- `Owner` MUST equal current owner in state
- `PreviousHash` MUST equal `CurrentState.LastTransactionHash`
- `NewOwnerKey` MUST be valid compressed public key (33 bytes)
- New owner address derived from `NewOwnerKey`
- IP MUST NOT be in BURNED status
Comment on lines 276 to +280

@gemini-code-assist gemini-code-assist Bot Oct 14, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The validation rules for IP Transfer Payload are missing checks for ContentHash and MetadataHash. The Version Control Semantics on line 141 and the purpose on line 256 state that a transfer is for "ownership transfer only" and the version is unchanged. This implies that content and metadata should not change. To enforce this, validation rules should be added to ensure ContentHash and MetadataHash match the current state.

Suggested change
- `Owner` MUST equal current owner in state
- `PreviousHash` MUST equal `CurrentState.LastTransactionHash`
- `NewOwnerKey` MUST be valid compressed public key (33 bytes)
- New owner address derived from `NewOwnerKey`
- IP MUST NOT be in BURNED status
- `ContentHash` MUST equal `CurrentState.ContentHash`
- `MetadataHash` MUST equal `CurrentState.MetadataHash`
- `Owner` MUST equal current owner in state
- `PreviousHash` MUST equal `CurrentState.LastTransactionHash`
- `NewOwnerKey` MUST be valid compressed public key (33 bytes)
- New owner address derived from `NewOwnerKey`
- IP MUST NOT be in BURNED status


**ProofHash Calculation**:

$$
ProofHash_{TRANSFER} = H(ContentID \parallel ContentHash \parallel MetadataHash
\parallel Version \parallel PreviousHash \parallel NewOwnerKey)
$$

**Transfer Semantics**: The transfer operation changes ownership but preserves the content version.
This ensures that version numbers have semantic meaning related to content changes, not ownership changes.
The new owner receives the IP at its current content version.

### 4. IP Burn Payload (PayloadType: `10`)

**Purpose**: Permanent destruction of IP ownership, preventing all future operations

**Payload Structure**:

| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (previous + 1) | ✅ |
| PreviousHash | `Hash` | 32 Bytes | Hash of previous IP transaction | ✅ |
| BurnReason | `string` | 100 Bytes | Optional reason for destruction (UTF-8) | *3 |
| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed ProofHash | ✅ |
Comment on lines +299 to +305

@gemini-code-assist gemini-code-assist Bot Oct 14, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

The IP Burn Payload structure is missing the Owner field. However, the validation rules on line 315 state that the Owner MUST equal the current owner in the state. This is a critical omission, as it's unclear how the owner is identified for authorization. For consistency with IP Update and IP Transfer payloads, and to ensure clarity and security, the Owner field should be included in this payload.

Adding this field would also impact the Payload Size Analysis table on line 156.

Suggested change
| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (previous + 1) | ✅ |
| PreviousHash | `Hash` | 32 Bytes | Hash of previous IP transaction | ✅ |
| BurnReason | `string` | 100 Bytes | Optional reason for destruction (UTF-8) | *3 |
| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed ProofHash | ✅ |
| Field | Type | Size | Description | Required |
|-------|------|------|-------------|----------|
| ContentID | `Hash` | 32 Bytes | Permanent IP identifier | ✅ |
| Owner | `Address` | 21 Bytes | Current owner address | ✅ |
| Version | `uint32` | 4 Bytes | Sequential version number (previous + 1) | ✅ |
| PreviousHash | `Hash` | 32 Bytes | Hash of previous IP transaction | ✅ |
| BurnReason | `string` | 100 Bytes | Optional reason for destruction (UTF-8) | *3 |
| Signature | `Bytes` | 64 Bytes | Ed25519/ECDSA signature of computed ProofHash | ✅ |


**Privacy Notes**:

- `*3`: Optional burn reason - can be omitted or zeroed for privacy

**Validation Rules**:

- `ContentID` MUST match existing IP state
- `Version` MUST equal `CurrentState.Version + 1`
- `Owner` MUST equal current owner in state
- `PreviousHash` MUST equal `CurrentState.LastTransactionHash`
- IP MUST NOT already be in BURNED status
- Only current owner can burn IP

**Effects of Burn Operation**:

- No future Update, Transfer, or Burn operations allowed
- IP becomes permanently frozen and unusable
- All historical data remains accessible for provenance

**ProofHash Calculation**:

$$ProofHash_{TRANSFER} = H(ContentHash \parallel MetadataHash \parallel Version \parallel PreviousHash \parallel NewOwnerKey)$$
$$ProofHash_{BURN} = H(ContentID \parallel Version \parallel PreviousHash \parallel BurnReason)$$

**Use Cases for IP Burn**:

- **Copyright Expiration**: When legal protection period ends
- **Voluntary Relinquishment**: Owner chooses to release ownership
- **Legal Compliance**: Court orders or regulatory requirements
- **Asset Retirement**: Business decision to retire digital assets
- **Privacy Protection**: Permanent removal from active circulation

## Cryptographic Specifications

Expand Down
Binary file added assets/aip-3/chain.jpg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file removed assets/aip-3/chain.png
View file
Open in desktop
Binary file not shown.