Delegated Token Transfer

Five steps: first user pre-positions tokens, entity requests payment, second user forwards tokens, system validates, data objects released.

The delegation flow is asynchronous: the first user pre-positions tokens (the setup step) independently of when payment requests arrive. When requests come in, the second user — who holds the pre-positioned tokens — acts as the authorization intermediary. Their token forwarding is the authorization signal the system validates before releasing value.

Three rule types: authorized user list, per-transfer cap, and transfer-type whitelist. Dual-prong validation: both authorization AND cap must clear before release.

The smart contract at the first user's data file stores three categories of delegation rules. Authorization rules define which second users are permitted to act as delegates — an identity-based whitelist. Cap rules define the maximum token amount per individual transfer — even an authorized delegate cannot exceed this limit per transaction. Type whitelist rules define which categories of transfer the delegate is permitted to execute on the first user's behalf.

The dual-prong validation — Claims 5/12/19 — requires that both the authorization check AND the cap check pass independently. A delegate who is authorized but over-cap is rejected. A transfer that is under-cap but not in the authorized user list is rejected. A transfer type not in the whitelist (Claims 6/13/20) is rejected regardless of whether the amount and authorization pass. All three rule types are enforced simultaneously before any data objects are released.

Basic delegation, cap rejection, whitelist enforcement, and multi-period delegation — four scenarios through the smart contract rule engine.

Select a scenario to trace a delegated payment through the authorization, cap, and whitelist validation chain — and see how the smart contract rules interact with the token forwarding mechanism.

The delegation pattern exists everywhere in traditional finance — corporate treasury, payroll delegation, authorized signatory accounts. This patent brings all three onto the blockchain, with enforced rules.

Delegation of payment authority is a foundational concept in institutional finance. A corporate treasurer delegates payment authority to a finance manager for operational expenses below a certain threshold. An individual delegates recurring bill payments to a property manager. A business owner delegates payroll execution to a payroll service provider. In each case, the delegate has specific, bounded authority — not unlimited access.

US12452066B2 encodes these real-world delegation patterns as on-chain smart contract rules. The three-rule architecture — authorization, cap, type whitelist — maps directly to how institutional payment delegation actually works: who can pay (authorization), how much per transaction (cap), and what category of payment (type whitelist). The token pre-positioning mechanism makes the delegation visible and auditable on the blockchain, without requiring the delegator to be present or active at payment time.

Corporate treasury automation, subscription service payment rails, DeFi protocol governance, and cross-border payment delegation — anywhere bounded authority needs blockchain enforcement.

The core value of US12452066B2 is transforming a legal and contractual concept — bounded payment delegation — into an on-chain, self-enforcing smart contract mechanism. The delegate's authority is always precisely what the smart contract says it is, enforced at execution time with no possibility of exceeding the defined bounds.

Forward Citations

No forward citations found as of this check. US12452066B2 was granted October 2025. Citation data is still accumulating. Verify the current list on Google Patents.

The 34th granted patent in a portfolio spanning edge computing, AI/ML, blockchain infrastructure, satellite communications, ATM operations, biometrics, and data privacy.

US12452066B2 is the last of 34 granted patents — filed in January 2024, granted in October 2025. The portfolio spans 6 years of continuous invention activity across 7 distinct technology domains, with 4 sole-inventor patents and multiple coordinated sibling pairs filed on the same date by the same inventors.

The blockchain patents — P28 (NFT routing), P29 (token rules), P30 (token split/burn), P33 (pull-payment), and P34 (this patent, delegation) — represent the most recent cluster, reflecting a shift from infrastructure and network patents toward digital asset and distributed ledger mechanics. 13 continuation applications remain pending, suggesting the portfolio is actively growing.