IP Library Granted Patent US 12689671
Granted Patent B1
US 12689671 · App. 19/535,955 · Granted Jul 21, 2026

Interoperable, wrapped tokens

Inventors: Gregory Di Prisco (New York, NY); Antonina Cherednichenko (New York, NY); Pierrick Turelier (Austin, TX)
Assignee: The Next Thing Ltd.
H04L67/10G06F21/10H04L63/20
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12689671
App. No.
19/535,955
Granted
Jul 21, 2026
Kind
B1
Abstract

Provided is a process including: minting a base token with a base-token smart contract on a blockchain; wrapping the base token with a first-type of wrapper token with a first wrapper smart-contract on the blockchain; receiving a request to transfer the base token to a second-type of wrapper token; and in response to receiving the requested transfer: unwrapping the base token from the first-type of wrapper token and wrapping the base token with a second-type of wrapper token with a second wrapper smart-contract on the blockchain.

Claims (79)

1 . A tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors effectuate operations comprising:

minting a base token with a base-token smart-contract on a blockchain, the base token being rendered a rivalrous asset by the blockchain;

wrapping the base token with a first-type of wrapper token with a first wrapper smart-contract on the blockchain, wherein the wrapping comprises:

minting the first-type of wrapper token,

transferring the base token to a first wrapper blockchain account partially, but not fully, controlled by the first wrapper smart-contract, and

transferring the minted first-type of wrapper token to a first user blockchain account without also transferring the base token to the first user blockchain account;

receiving a request to transfer the base token to a second-type of wrapper token; and

in response to receiving the requested transfer:

determining that the requested transfer complies with rules in a policy associated with the first wrapper smart-contract;

unwrapping the base token from the first-type of wrapper token; and

wrapping the base token with a second-type of wrapper token with a second wrapper smart-contract on the blockchain, wherein:

the second wrapper smart-contract is associated with a different policy from the policy associated with the first wrapper smart-contract, and

the base token is transferred to a second wrapper blockchain account partially, but not fully, controlled by the second wrapper smart-contract.

2 . The medium of claim 1 , wherein:

the first-type of wrapper token earns yield without increasing the number of first-type of wrapper tokens of the first user blockchain account.

3 . The medium of claim 1 , wherein:

the requested transfer's compliance with the policy associated with the first wrapper smart-contract is determined by the first wrapper smart-contract or another smart-contract on the blockchain.

4 . The medium of claim 1 , wherein:

the requested transfer's compliance with the policy associated with the first wrapper smart-contract is determined by code not executed by a computing platform implementing the blockchain.

5 . The medium of claim 1 , wherein:

the base token is a stable coin backed by an asset; and

the first-type of wrapper token and the second-type of wrapper token are stable coins backed by the base token.

6 . The medium of claim 1 , wherein:

the entity that created the first-type of wrapper token and the entity that created the second-type of wrapper token are each not stable coin issuers and do not own the base token when wrapped with their respective wrapper tokens.

7 . The medium of claim 1 , wherein:

interoperability of the base token between the first-type of wrapper token and the second-type of wrapper token is implemented with a router smart-contract that is independent of the first wrapper smart-contract and the second wrapper smart-contract.

8 . The medium of claim 1 , wherein:

interoperability of the base token between the first-type of wrapper token and the second-type of wrapper token is implemented by the first wrapper smart-contract, the second wrapper smart-contract, or both.

9 . The medium of claim 1 , wherein (a) the minting the first-type of wrapper token and (b) the transferring the base token to the first wrapper blockchain account partially, but not fully, controlled by the first wrapper smart-contract occur substantially simultaneously.

10 . The medium of claim 1 , wherein the partial control of the first and second wrapper smart-contracts includes an ability to selectively block transfers of the base token.

11 . The medium of claim 10 , wherein the partial control of the first and second wrapper smart-contracts does not include the ability to transfer the base token to blockchain accounts that are not pre-approved in a registry controlled by a different entity from entities specifying policies associated with the first-type of wrapper token and the second-type of wrapper token.

12 . The medium of claim 1 , the operations further comprising:

steps for wrapping the base token with the second-type of wrapper token with the second wrapper smart-contract on the blockchain.

13 . The medium of claim 1 , wherein the blockchain comprises a first blockchain network and a second blockchain network, and wherein a spoke portal smart-contract on the second blockchain network (a) receives an epoch update originating from a hub portal smart-contract on the first blockchain network, (b) verifies authenticity of the epoch update based on cryptographic proof data, (c) rejects the epoch update based on a freshness rule stored on the second blockchain network, and (d) stores the epoch update in chain state of the second blockchain network for use in determining that the requested transfer complies with the policy associated with the first wrapper smart-contract or the policy associated with the second wrapper smart-contract.

14 . The medium of claim 1 , wherein determining that the requested transfer complies with rules in the policy comprises verifying, on the blockchain, a cryptographic membership proof that a destination blockchain account is included in a set of permitted destination blockchain accounts represented by a digest stored in chain state, wherein the cryptographic membership proof is bound to an epoch identifier stored in chain state.

15 . The medium of claim 1 , wherein the base-token smart-contract maintains, in chain state, an index value that is monotonically non-decreasing over time, and wherein the first-type of wrapper token and the second-type of wrapper token are non-rebasing such that balances of the first-type of wrapper token and balances of the second-type of wrapper token do not change in response to changes in the index value.

16 . The medium of claim 1 , wherein receiving the request to transfer the base token to the second-type of wrapper token comprises receiving, by a router smart-contract, a message that includes an authorization memo, and wherein at least one of the first wrapper smart-contract or the second wrapper smart-contract is configured to reject an unwrap or wrap operation unless the authorization memo satisfies a memo rule stored on the blockchain.

17 . The medium of claim 1 , wherein the first-type of wrapper token and the second-type of wrapper token are designated as being issued by different entities.

18 . The medium of claim 1 , wherein: (a) the blockchain maintains a replicated chain state that stores, for the base token, at least a balance mapping from blockchain accounts to base-token amounts and rejects any proposed state transition that would debit a base-token amount from a blockchain account without a valid cryptographic authorization attributable to that blockchain account or that would cause the base-token amount of that blockchain account to become negative; (b) the wrapping of the base token with the first-type of wrapper token is performed within execution of a single blockchain transaction that (i) effects the transferring of the base token from the first user blockchain account to the first wrapper blockchain account and (ii) effects the minting of the first-type of wrapper token to the first user blockchain account; (c) the first wrapper blockchain account is an account whose ability to transfer the base token out of the first wrapper blockchain account is constrained such that a transfer out of the first wrapper blockchain account is valid only when the transfer is invoked by the first wrapper smart-contract and the transfer additionally satisfies a second authorization requirement that is distinct from the first wrapper smart-contract; (d) the policy associated with the first wrapper smart-contract is represented on-chain by at least one policy record that includes a policy identifier and a cryptographic digest of a corresponding rule set, and determining that the requested transfer complies with rules in the policy comprises evaluating, by on-chain code, at least one rule predicate that references a registry of pre-approved destination blockchain accounts; and (e) receiving the request to transfer the base token to the second-type of wrapper token comprises receiving, by a router smart-contract that is independent of the first wrapper smart-contract and the second wrapper smart-contract, a call that identifies at least the first wrapper smart-contract, the second wrapper smart-contract, and a requested base-token amount, wherein the unwrapping of the base token from the first-type of wrapper token and the wrapping of the base token with the second-type of wrapper token occur within execution of the call.

19 . A method, comprising causing a blockchain computing platform to perform operations comprising:

minting a base token with a base-token smart-contract on a blockchain, the base token being rendered a rivalrous asset by the blockchain;

wrapping the base token with a first-type of wrapper token with a first wrapper smart-contract on the blockchain, wherein the wrapping comprises:

minting the first-type of wrapper token,

transferring the base token to a first wrapper blockchain account partially, but not fully, controlled by the first wrapper smart-contract, and

transferring the minted first-type of wrapper token to a first user blockchain account without also transferring the base token to the first user blockchain account;

receiving a request to transfer the base token to a second-type of wrapper token; and

in response to receiving the requested transfer:

determining that the requested transfer complies with rules in a policy associated with the first wrapper smart-contract;

unwrapping the base token from the first-type of wrapper token; and

wrapping the base token with a second-type of wrapper token with a second wrapper smart-contract on the blockchain, wherein:

the second wrapper smart-contract is associated with a different policy from the policy associated with the first wrapper smart-contract, and

the base token is transferred to a second wrapper blockchain account partially, but not fully, controlled by the second wrapper smart-contract.

20 . The method of claim 19 , wherein:

the first-type of wrapper token earns yield without increasing the number of first-type of wrapper tokens of the first user blockchain account.

21 . The method of claim 19 , wherein:

the requested transfer's compliance with the policy associated with the first wrapper smart-contract is determined by the first wrapper smart-contract or another smart-contract on the blockchain.

22 . The method of claim 19 , wherein:

the requested transfer's compliance with the policy associated with the first wrapper smart-contract is determined by code not executed by a computing platform implementing the blockchain.

23 . The method of claim 19 , wherein:

the base token is a stable coin backed by an asset; and

the first-type of wrapper token and the second-type of wrapper token are stable coins backed by the base token.

24 . The method of claim 19 , wherein:

the entity that created the first-type of wrapper token and the entity that created the second-type of wrapper token are each not stable coin issuers and do not own the base token when wrapped with their respective wrapper tokens.

25 . The method of claim 19 , wherein:

interoperability of the base token between the first-type of wrapper token and the second-type of wrapper token is implemented with a router smart-contract that is independent of the first wrapper smart-contract and the second wrapper smart-contract.

26 . The method of claim 19 , wherein:

interoperability of the base token between the first-type of wrapper token and the second-type of wrapper token is implemented by the first wrapper smart-contract, the second wrapper smart-contract, or both.

27 . The method of claim 19 , wherein (a) the minting the first-type of wrapper token and (b) the transferring the base token to the first wrapper blockchain account partially, but not fully, controlled by the first wrapper smart-contract occur substantially simultaneously.

28 . The method of claim 19 , wherein the partial control of the first and second wrapper smart-contracts includes an ability to selectively block transfers of the base token.

29 . The method of claim 28 , wherein the partial control of the first and second wrapper smart-contracts does not include the ability to transfer the base token to blockchain accounts that are not pre-approved in a registry controlled by a different entity from entities specifying policies associated with the first-type of wrapper token and the second-type of wrapper token.

30 . The method of claim 19 , further comprising:

steps for wrapping the base token with the second-type of wrapper token with the second wrapper smart-contract on the blockchain.

31 . The method of claim 19 , wherein the blockchain comprises a first blockchain network and a second blockchain network, and wherein a spoke portal smart-contract on the second blockchain network (a) receives an epoch update originating from a hub portal smart-contract on the first blockchain network, (b) verifies authenticity of the epoch update based on cryptographic proof data, (c) rejects the epoch update based on a freshness rule stored on the second blockchain network, and (d) stores the epoch update in chain state of the second blockchain network for use in determining that the requested transfer complies with the policy associated with the first wrapper smart-contract or the policy associated with the second wrapper smart-contract.

32 . The method of claim 19 , wherein determining that the requested transfer complies with rules in the policy comprises verifying, on the blockchain, a cryptographic membership proof that a destination blockchain account is included in a set of permitted destination blockchain accounts represented by a digest stored in chain state, wherein the cryptographic membership proof is bound to an epoch identifier stored in chain state.

33 . The method of claim 19 , wherein the base-token smart-contract maintains, in chain state, an index value that is monotonically non-decreasing over time, and wherein the first-type of wrapper token and the second-type of wrapper token are non-rebasing such that balances of the first-type of wrapper token and balances of the second-type of wrapper token do not change in response to changes in the index value.

34 . The method of claim 19 , wherein receiving the request to transfer the base token to the second-type of wrapper token comprises receiving, by a router smart-contract, a message that includes an authorization memo, and wherein at least one of the first wrapper smart-contract or the second wrapper smart-contract is configured to reject an unwrap or wrap operation unless the authorization memo satisfies a memo rule stored on the blockchain.

35 . The method of claim 19 , wherein the first-type of wrapper token and the second-type of wrapper token are designated as being issued by different entities.

36 . The method of claim 19 , wherein: (a) the blockchain maintains a replicated chain state that stores, for the base token, at least a balance mapping from blockchain accounts to base-token amounts and rejects any proposed state transition that would debit a base-token amount from a blockchain account without a valid cryptographic authorization attributable to that blockchain account or that would cause the base-token amount of that blockchain account to become negative;

(b) the wrapping of the base token with the first-type of wrapper token is performed within execution of a single blockchain transaction that (i) effects the transferring of the base token from the first user blockchain account to the first wrapper blockchain account and (ii) effects the minting of the first-type of wrapper token to the first user blockchain account; (c) the first wrapper blockchain account is an account whose ability to transfer the base token out of the first wrapper blockchain account is constrained such that a transfer out of the first wrapper blockchain account is valid only when the transfer is invoked by the first wrapper smart-contract and the transfer additionally satisfies a second authorization requirement that is distinct from the first wrapper smart-contract; (d) the policy associated with the first wrapper smart-contract is represented on-chain by at least one policy record that includes a policy identifier and a cryptographic digest of a corresponding rule set, and determining that the requested transfer complies with rules in the policy comprises evaluating, by on-chain code, at least one rule predicate that references a registry of pre-approved destination blockchain accounts; and (e) receiving the request to transfer the base token to the second-type of wrapper token comprises receiving, by a router smart-contract that is independent of the first wrapper smart-contract and the second wrapper smart-contract, a call that identifies at least the first wrapper smart-contract, the second wrapper smart-contract, and a requested base-token amount, wherein the unwrapping of the base token from the first-type of wrapper token and the wrapping of the base token with the second-type of wrapper token occur within execution of the call.