Platform

Overview

How It Works

Beneficiary Identity

Policy Corridors

Deterministic Finality

Architecture

Security Model

Governance

Integration

Solutions

Corridors Overview

Institutional Overview

Pricing

All Scenarios

Humanitarian Impact Fund

Assurance

Technical Assurance

Verify Receipt

Receipt Example

Developers

Documentation

APIs & Bridges

Architecture Docs

Glossary

BID API

Company

About

Team

Partners

Roadmap

Investors

Contact

Blog

All Documentation

Schedule Consultation
← Back to Patent Claims
Patent Claim 28 All Patents →

Immutable Transfer Compliance

Per-Transfer Fee Enforcement and Compliance Rules Embedded in Token Contracts

Patent Claim JIL Sovereign February 2026 Claim 28 of 36

Executive Summary

JIL Sovereign's token factory embeds five immutable compliance parameters at token deployment that are enforced inside the core do_transfer() function on every transfer call. These rules cannot be disabled, upgraded away, or bypassed by any party including the token issuer.

Core Innovation: Compliance rules are embedded at the transfer level, not at the contract level. Every single token transfer passes through the compliance checks - there is no alternative code path.

Five Immutable Parameters

ParameterPurposeEnforcement
Zone RestrictionsGeographic compliance zones where token can circulateTransfer rejected if recipient not in allowed zone
Transferability FlagWhether token can be freely transferredTransfer rejected if flag is false
Humanity FeeBasis-point deduction per transfer routed to designated poolAutomatic deduction on every transfer
Account FreezingAbility to freeze specific accountsTransfer rejected if sender or recipient frozen
Certification IDKYB verification reference for the token issuerImmutable record linking token to verified entity

Transfer Function Integration

function do_transfer(from, to, amount, token) {
    // 1. Zone check
    if (!token.allowed_zones.includes(get_zone(to)))
        REJECT("Recipient not in allowed zone")

    // 2. Transferability check
    if (!token.transferable)
        REJECT("Token transfers disabled")

    // 3. Freeze check
    if (is_frozen(from) || is_frozen(to))
        REJECT("Account frozen")

    // 4. Humanity fee deduction
    fee = amount * token.humanity_fee_bps / 10000
    net_amount = amount - fee
    transfer(from, token.fee_pool, fee)

    // 5. Execute transfer
    transfer(from, to, net_amount)
}

Cooldown Activation

Newly deployed tokens enter a Pending state for a configurable delay period before becoming Active. This prevents immediate post-deployment pump-and-dump schemes by giving the market time to evaluate the token.

Issuer TypeCooldown PeriodRate Limit
Unverified24 hours1 deployment per day
Certified1 hour (fast-track)10 deployments per day

Business Impact

The humanity fee mechanism creates a continuous social impact revenue stream. At a default 10 bps and $1B daily transfer volume across all JIL20 tokens, this generates approximately $365K per year per basis point in social impact funding.

The immutable nature of these rules provides regulatory certainty: regulators can verify that compliance is technically enforced, not merely promised. This satisfies MiCA tokenization requirements without additional infrastructure.

Patent Claim

Dependent Claim 28: The system of claim 26, wherein the cooldown-based activation enforces a 24-hour standard delay for unverified issuers and a 1-hour fast-track delay for certified issuers, combined with per-issuer rate limiting of maximum 10 deployments per day.