Blockchain Token Locking Scripts Enforcing Consistent Mechanics

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for creating tokens on blockchain networks decouple them from their native assets, requiring burdensome coordination and preventing mass adoption due to the inability to enforce token mechanics consistently.

Innovation Solution

Tokens are represented as single units of the underlying digital asset, with a locking script that includes a variable component for ownership transfer and a constant component enforcing token mechanics, ensuring tokens can only be spent under specific conditions, maintaining their integrity throughout transactions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If tokens are created using additional data fields in transactions (previous approach), then tokens can be created on blockchain, but token mechanics cannot be enforced consistently and coordination becomes burdensome

Engineering Contradiction:
Improvetoken creation flexibilityVSAvoidtoken mechanics enforcement
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent merges the token data with the underlying digital asset by using the same transaction output to represent both. The token is not a separate entity but is embedded within the native asset structure, eliminating the need for separate token protocols and enabling consistent enforcement of token mechanics through the existing blockchain validation logic.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent makes the underlying digital asset serve multiple functions: it acts as both the native currency and the token simultaneously. By encoding token-specific data within the native asset's transaction output, the system achieves multi-functionality without requiring separate token infrastructure, thereby ensuring reliable enforcement of token mechanics.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If tokens are decoupled from native assets (previous approach), then tokens can have independent properties, but coordination becomes burdensome and mass adoption is prevented

Engineering Contradiction:
Improvetoken independenceVSAvoidcoordination complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent combines token independence with native asset simplicity by embedding token properties within the native asset structure. Rather than decoupling tokens completely, the invention maintains a unified representation where token-specific data fields coexist with native asset functionality, reducing coordination complexity while preserving token independence.

Inventive Principle:
Principle #5Merging (Combining)

3Ease of manufacture

If tokens use additional data structures (previous approach), then tokens can be created, but the system becomes complex and prevents mass adoption

Engineering Contradiction:
Improvetoken creation easeVSAvoidsystem complexity
Core Design Contradiction:
Ease of manufactureVSDevice complexity

Solution Approach 1:

The patent enables easy token creation by making the native digital asset serve as the token载体. The same transaction structure used for native asset transfer is now universally used for token transfer as well, eliminating the need for complex separate token creation mechanisms and reducing system complexity while maintaining ease of manufacture.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS12362935B2Blockchain tokens
Publication Date: 2025.07.15 TERANODE INFRASTRUCTURE SERVICES GMBH
  • US12362935B2 patent drawing
  • US12362935B2 patent drawing
  • US12362935B2 patent drawing

AI summary

A token transaction comprising a first token output, the first token output comprising a first token locking script and a first token amount, wherein the first token locking script comprises a variable component and a constant component, wherein the variable component comprises a first payment address, embedded in a payment template, and wherein the constant component comprises a token mechanics sub-component.