Blockchain network congestion adaptive digital asset event handling system and method

Abstract

A computer-implemented method and system for blockchain network congestion adaptive handling of events related to digital assets, including create operations and transfer operations. Congestion metrics are measured to determine the current congestion of the blockchain network. If below a first threshold level, the requests are implemented using blockchain transactions at layer 1 as they are received. If the metrics are above the first threshold level, the received requests are queued until a queue trigger is detected, whereupon the queued requests are processed at layer 2 and implemented using bulk blockchain transactions by recording updated states on the chain. When the metrics drop below a second threshold, the process reverts to using layer 1 blockchain transactions rather than queuing requests for bulk processing at layer 2.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to digital assets, and in particular to systems and methods for blockchain network congestion adaptive digital asset creation or transfer. BACKGROUND

[0002] Distributed computing networks can facilitate the exchange of digital assets. In particular, blockchain operating platforms can handle the creation and transfer of digital assets. In some cases, a digital asset can be a token that represents or corresponds to a real-world asset or unique item. Ownership or transactions of the token can represent ownership or transactions of the underlying tokenized asset. In some cases, the asset is unique such that the token is a non-fungible token; that is, the token is also unique.

[0003] One of the challenges with using many current blockchain networks is that they have become so popular that they have become congested and are having difficulty scaling. Congestion of the network can result in long lag times for transaction confirmation, and / or excessive resource usage or transaction fee costs to include transactions in mined blocks.

[0004] It would be advantageous to provide improved methods and systems for handling digital asset events, such as the creation or transfer of digital assets. BRIEF DESCRIPTION OF DRAWINGS

[0005] Embodiments will be described, by way of example only, with reference to the accompanying drawings in which:

[0006] Figure 1 An example blockchain network is illustrated;

[0007] Figure 2 An example system for processing events involving non-fungible tokens is illustrated;

[0008] Figure 3 An example method for processing events involving non-fungible tokens based on network congestion metrics is illustrated in the form of a flowchart;

[0009] Figure 4 is a block diagram of an e-commerce platform in accordance with example embodiments; and

[0010] Figure 5 is an example of an administrator’s home page in accordance with example embodiments. SUMMARY

[0011] Accordingly, there is provided a computer implemented method, a computing system, a computer program and a computer readable medium as described in detail in the appended claims. DETAILED DESCRIPTION

[0012] In one aspect, the present application discloses a computer-implemented method that can include receiving a first non-fungible token transaction request; obtaining a network congestion indicator regarding a congestion measure of a blockchain network; determining that the network congestion indicator is above a first threshold level; and in response to determining that the network congestion indicator is above the first threshold level, queuing the first non-fungible token transaction request and detecting a queue trigger, and in response, generating and propagating a bulk blockchain transaction on the blockchain network, the bulk blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request.

[0013] In some embodiments, the additional non-fungible token transaction request is received after the first non-fungible token transaction request and is appended to a queue containing the first non-fungible token transaction request.

[0014] In some embodiments, the network congestion indicator is based on one or more of: a count of unconfirmed transactions on the blockchain network, a rate of receipt of new transactions on the blockchain network, an average age of unconfirmed transactions on the blockchain network, a rate of change in the number of unconfirmed transactions over a window of time, a cost measure of each computational operation, or a transaction fee.

[0015] In some embodiments, detecting the queue trigger includes one or more of: determining that a time elapsed since receiving the first non-fungible token transaction request has exceeded a maximum time, determining that a count of requests in the queue matches or exceeds a maximum count, or determining that the network congestion indicator has fallen below a second threshold level. In some cases, the second threshold level matches the first threshold level.

[0016] In some embodiments, queuing includes storing at least a portion of data from the first non-fungible token transaction request in a memory, the portion of data being sufficient to generate a blockchain transaction implementing the first non-fungible token transaction request.

[0017] In some embodiments, wherein the bulk blockchain transaction references a bulk processing function and provides an updated NFT state to reflect implementation of the two or more non-fungible token transaction requests.

[0018] In some embodiments, the first non-fungible token transaction request is a minting request and includes a recipient address. In some cases, the at least one additional non-fungible token transaction request is another minting request and includes a respective recipient address.

[0019] In some embodiments, the queued non-fungible token transaction requests include at least one transfer request regarding a previously minted token, and the at least one transfer request includes a transferee address and a digital signature.

[0020] In some embodiments, the method can further include, after generating and propagating the batch blockchain transaction: receiving a second non-fungible token transaction request; obtaining an updated network congestion indicator regarding a congestion measure of the blockchain network; determining that the updated network congestion indicator is below the first threshold level; and in response to determining that the updated network congestion indicator is below the first threshold level, generating and sending a single blockchain transaction on the blockchain network to individually implement the second non-fungible token transaction request without queuing.

[0021] In another aspect, the present application describes a computing system including a processor and a memory. The memory can store computer-executable instructions that, when executed, cause the processor to perform operations of one or more of the methods described herein.

[0022] In yet another aspect, the present application describes a computer-readable medium having stored computer-executable instructions that, when executed by a processor, cause the processor to perform operations of one or more of the methods described herein. The computer-readable medium can be non-transitory.

[0023] Other example embodiments of the present disclosure will be apparent to those of ordinary skill in the art in view of the following detailed description in conjunction with the attached drawings.

[0024] In this application, the term "and / or" is intended to encompass all possible combinations of the elements listed, including any one of the listed elements alone, any combination or all of the elements, and is not necessarily intended to exclude additional elements.

[0025] In this application, the phrase "at least one of... and..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any combination or all of the elements, and is not necessarily intended to exclude additional elements.

[0026] In this application, the term “e-commerce platform” broadly refers to computerized systems (or services, platforms, etc.) that facilitate commercial transactions (i.e., buying and selling activities) conducted over computer networks (e.g., the Internet). For example, an e-commerce platform can be a standalone online store, a social network, a social media platform, etc. A customer can initiate a transaction and an associated payment request via an e-commerce platform, and the e-commerce platform can be equipped with transaction / payment processing components or delegate such processing activities to one or more third-party services. An e-commerce platform can be extended / expanded by connecting one or more additional sales channels, which represent platforms where products can be sold. In particular, a sales channel can itself be an e-commerce platform, such as Facebook Shops TM , Amazon TM , etc.

[0027] In this application, the term “blockchain” is used to include all forms of computer- based electronic, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof.

[0028] A blockchain is a consensus-based electronic ledger, implemented as a computer- based decentralized, distributed system made up of blocks, which in turn are made up of transactions. Each transaction is a data structure that encodes some data or state. In many cases, the data recorded in a transaction concerns the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. In some cases, a transaction can invoke code recorded in another transaction on the blockchain. This code can be referenced and executed by further transactions, and can be referred to as a “smart contract”.

[0029] Each block in a blockchain contains a hash of the previous block, so that blocks are linked together in order to create a permanent, unalterable record of all transactions written to the blockchain since its inception. Transactions can contain small programs, called scripts, embedded into their inputs and outputs, which specify how and by whom the outputs of a transaction can be accessed.

[0030] A network node that receives a new transaction attempts to propagate the transaction to other nodes in the network, i.e., broadcast the transaction on the blockchain network. Before transmitting a new transaction to other nodes, the transaction is “validated”; that is, the transaction is checked against a set of criteria to ensure that the transaction meets the basic requirements for a correct transaction according to the applicable blockchain protocol, so as to avoid invalid transactions from clogging the network.

[0031] To write a transaction to the blockchain, transactions are incorporated into blocks by nodes designed to collect transactions and form them into blocks (“miners” or “mining nodes”). Miners then attempt to complete a “proof of work” with respect to that node. In some cases, the blockchain can rely on a “proof of stake” or other mining mechanism. Proof of work miners throughout the blockchain network compete to be the first to assemble a block of transactions and complete the proof of work associated with that block. The successful miner adds its confirmed block to the blockchain, and the block propagates through the network so that other nodes maintaining copies of the blockchain can update their records. Those nodes that receive the block also “validate” the block and all transactions therein to ensure that the transactions meet the formal requirements of the protocol.

[0032] A “digital asset” refers to an asset in digital format and having a right of use. In particular, a digital asset is self-contained, uniquely identifiable, and associated with a defined value or use capability. Examples of digital assets include digital documents, multimedia files (e.g., photographs, audiovisual media, animations, etc.), emails, websites, cryptocurrencies, digital wallets, and asset-backed tokens, among others.

[0033] Blockchain technology creates new efficiencies in the marketplace and is often the preferred medium for exchanging digital assets. A blockchain allows parties to explicitly prove certain aspects of a digital asset, such as ownership, authenticity, and transaction history, without involving a centralized or intermediary entity. A blockchain produces a data structure with inherent security qualities. Combining cryptography, decentralization, and consensus mechanisms, blockchain technology can ensure trust in transactions conducted on a blockchain operating platform without needing to trust a third-party intermediary.

[0034] The rapid growth of software applications and the space for blockchain-based assets has spawned various different types of digital assets. One example of a class of digital assets that has garnered significant attention is non-fungible tokens (NFTs). NFTs are unique digital assets with blockchain-based authenticity, ownership, and transferability features. More specifically, NFTs are units of data stored on a blockchain that prove the uniqueness of a digital asset. NFTs can represent a wide range of assets, whether physical or digital, including but not limited to: digital art, collectibles, music, digital movies, games, etc. NFTs act as a digital certificate of ownership for any assigned digital asset. A key feature of NFTs is that they cannot be interchanged with one another—each NFT has a unique identification code and metadata that makes it distinguishable from any other NFT. The unique identity and ownership of an NFT can be verified using a blockchain ledger.

[0035] Blockchain networks like Ethereum have a token standard, enabling developers to deploy NFTs and ensure they are compatible with a broader ecosystem, including transaction and wallet services. NFTs can be bought and sold through on-chain or off-chain transactions.

[0036] A smart contract for generating digital assets such as NFTs can be deployed on a blockchain (e.g., an Ethereum blockchain). The smart contract can include code that, when executed, generates an NFT with a unique identifier. This is often referred to as “minting” the NFT. The creation event of the NFT and its unique ID can be recorded on the blockchain. The smart contract code can further provide functions such as a transfer function. NFTs can be transferred between accounts (e.g., addresses), and ownership change events are recorded in an immutable ledger. In many implementations, in addition to the overall virtual machine state (e.g., Ethereum Virtual Machine), the smart contract is configured to maintain an NFT ledger or state that reflects the state and history of NFT minting and ownership. This can be referred to herein as the “NFT state” or “NFT ledger.” In some examples, NFTs can be implemented using a smart contract that complies with the Ethereum Request for Comments (ERC) 721 standard for non-fungible tokens. In some examples, NFTs can be implemented using a smart contract that complies with the ERC-1155 standard for multi-token minting. In some other examples, NFTs can be implemented using a smart contract that complies with another standard.

[0037] One of the challenges facing many current blockchain protocols is that their increasing popularity has caused a corresponding increase in network congestion, leading to increased transaction costs. In the Bitcoin network, the cost of including a transaction in a mined block is referred to as a “transaction fee.” In the Ethereum network, the cost of including a transaction in a mined block can include a transaction fee and a “gas” cost, where the gas cost refers to a cost attributed to the number and / or complexity of code operations required by a transaction. For example, if a transaction event invokes a particular portion of a smart contract, the gas price can depend on the number (or complexity) of computational operations involved in executing that portion of the smart contract by the Ethereum Virtual Machine.

[0038] Congestion and cost issues can result in significant delays in executing or recording transactions on-chain. Competition to get transactions included in a mined block more quickly causes miners to only select pending unconfirmed transactions that offer higher fees and greater potential rewards to the miners.

[0039] Some blockchain networks have attempted to address cost and congestion issues by creating or deploying off-chain tools or networks, within which events or transactions are performed, while periodically or occasionally checking and recording state on the actual blockchain. This additional network can be referred to as a“Layer 2” protocol, while the underlying blockchain protocol / network can be referred to as a“Layer 1” protocol. An example in the context of Bitcoin is the Lightning Network. Layer 2 solutions to congestion and cost attempt to remove a large number of transactions and events from the Layer 1 network, such that the higher-cost Layer 1 network is only occasionally used to record periodic states of accounts. Some drawbacks of this are that the Layer 2 network can be less secure or trustworthy, as the network lacks the core functionality of ensuring that all transactions are validated and verified by miners before being recorded on a distributed immutable ledger. The work of miners is only done at the occasional state recording. Furthermore, the delay between Layer 1 recordings can be as long or longer than the inherent delay of waiting for higher-cost transactions at Layer 1. Thus, while Layer 2 can help reduce the cost of recording every event or transaction at Layer 1, it can reduce or diminish some of the advantages of using blockchain technology, depending on the application and implementation.

[0040] It would be advantageous, particularly in the context of NFTs, to provide a method and system of minting and transferring that can reduce network congestion, congestion-related resource usage, and / or network latency.

[0041] Reference is first made to Figure 1 This figure illustrates, in block diagram form, an example network associated with a blockchain, which can be referred to herein as a blockchain network 201. The blockchain network 201 is an open membership peer-to-peer network, to which anyone can join without invitation or without the consent of other members. Distributed electronic devices running instances of the blockchain protocol by which the blockchain network 201 operates can participate in the blockchain network 201. Such distributed electronic devices can be referred to as nodes 202. The blockchain protocol can be, for example, Ethereum, Bitcoin, or another blockchain protocol.

[0042] The electronic devices that are nodes 202 running the blockchain protocol and forming the blockchain network 201 can be of various types, including, for example, computers (such as desktop computers, laptop computers, tablet computers, servers), mobile devices (such as smartphones), wearable computers (such as smart watches), or other electronic devices.

[0043] The nodes 202 of the blockchain network 201 are coupled to one another using suitable communication technology, which can include wired and wireless communication technology. In many cases, the blockchain network 201 is implemented at least partially through the Internet, and some of the nodes 202 can be located in geographically dispersed locations.

[0044] The nodes 202 maintain a global ledger of all transactions on the blockchain, grouped into blocks that each contain a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 202 can store a full or partial copy of the global ledger. Transactions that propagate across the network are validated by other nodes 202 before being included in a mined block, thereby maintaining the validity of the global ledger. Those of ordinary skill in the art will appreciate the details of implementing and operating a blockchain network, such as one using the Ethereum protocol.

[0045] Each transaction typically has one or more inputs and one or more outputs. Scripts can be embedded into the inputs and outputs, specifying how and by whom the outputs of a transaction can be used or transferred. The outputs of a transaction can be an address to which value (or a digital asset) is assigned as a result of the transaction. In some implementations, the value is then associated with that output address, for example as an unspent transaction output (UTXO). Subsequent transactions can then reference that address as an input in order to transfer or otherwise use the value or asset. In some cases, like Ethereum, code in the form of a smart contract can be deployed on the blockchain and can be called or referenced by later transactions to cause the network to execute the code. In this way, transactions can cause the network to perform certain functions, such as generating (minting) an NFT, or validating and effecting a transfer of an NFT from one owner address to a new owner address.

[0046] The nodes 202 can fulfill many different functions that are routed from the network to the wallet service, to maintain a robust and secure decentralized public ledger. In some implementations, a “full node” contains a complete and up-to-date copy of the blockchain, and can therefore validate any transaction (spent or unspent) on the public ledger. A “light node” (sometimes referred to as a simplified payment verification (SPV) in Bitcoin) does not include a copy of the blockchain, but can use a Merkle proof to validate a transaction and confirm that the transaction is included in a particular block. In some cases, a light node only downloads the headers of blocks, rather than the transactions within each block. “Mining nodes” participate in proof-of-work (or proof-of-stake in some cases) activity to compete to validate candidate blocks and propagate solutions across the network, thereby building the blockchain. The nodes 202 can communicate with each other using a connection-oriented protocol such as TCP / IP (transmission control protocol).

[0047] Figure 2 An exemplary computing environment 200 consistent with certain disclosed embodiments is shown. As Figure 2As shown, the computing environment 200 can include an e-commerce platform 105, a plurality of user devices 230, and a communication network 125 connecting one or more components of the computing environment 200. The communication network 125 can include one or more wired or wireless networks, including the Internet.

[0048] As shown, the user devices 230 and the e-commerce platform 105 can communicate via the communication network 125. In at least some embodiments, each user device 230 can be a computing device. The user devices 230 can take a variety of forms, including, for example, a mobile communication device such as a smartphone, a tablet computer, a wearable computer such as a head-mounted display or a smartwatch, a laptop computer or a desktop computer, or other types of computing devices.

[0049] One or more of the user devices 230 can be associated with a merchant or generator of a digital asset that intends to offer the digital asset to the public via the e-commerce platform 105. One or more of the user devices 230 can be associated with a buyer of a digital asset. In particular, one or more of the user devices 230 can be associated with a customer of a merchant offering a digital asset via the e-commerce platform 105. In at least some embodiments, the one or more of the user devices 230 can have a wallet application resident thereon. The wallet application can be a standalone mobile application, a web application accessible via a web browser, or a desktop application. The wallet application can be an application that allows a merchant and / or a buyer to interact with an account. The account can be an account of the e-commerce platform 105 and / or a blockchain network account. For example, the wallet application can allow a buyer to view a balance and transaction history, send transactions, encrypt and / or sign information, and connect to other applications. The wallet application can store various types of data, such as keys (e.g., public and / or private keys) for cryptocurrency transactions and digital assets (e.g., tokens such as NFTs) associated with the buyer.

[0050] In at least some embodiments, the e-commerce platform 105 can provide a processing facility for the transfer of digital assets bought and sold on the e-commerce platform. More specifically, components of the e-commerce platform 105 can be configured to control the generation and transfer of digital assets using a blockchain network.

[0051] The e-commerce platform 105 includes a commerce management engine 136, a digital asset request controller 210, and a data facility 134. The commerce management engine 136 can be configured to handle various operations related to e-commerce accounts associated with the e-commerce platform 105. For example, the commerce management engine 136 can be configured to retrieve e-commerce account information for various entities (e.g., merchants, customers, etc.) and historical account data (such as transaction event data, browsing history data, etc.) for selected e-commerce accounts. In particular, the commerce management engine 136 can obtain account information for a buyer’s and / or a merchant’s e-commerce account associated with the e-commerce platform 105.

[0052] In some cases, the e-commerce platform 105 can provide general e-commerce services that enable merchants to make various products or services available for purchase by customers in a virtual store or other virtual environment or marketplace. In this example, one of the available products can be a digital asset, such as an NFT. The NFT can be generated using smart contract code that is deployed and recorded on a blockchain. The smart contract code can also include executable functions for transferring the generated NFT from a current owner address to a new owner address.

[0053] The computing environment 200 can further include a blockchain network 201, which is shown as being deployed within and as part of the communication network 125. In some cases, the e-commerce platform 105 can act as one of the nodes 202 of the blockchain network 201. In some cases, the e-commerce platform 105 can not act as one of the nodes 202 and can send and receive blockchain-related data, such as transactions, via one or more of the nodes 202 in the blockchain network 201. The e-commerce platform 105 can employ various APIs or other functionality to securely communicate with the one or more nodes 202 in order to exchange blockchain data, messages, and instructions.

[0054] The digital asset request controller 210 can be a software-implemented module that contains processor-executable instructions that, when executed by one or more processors in the e-commerce platform 105, cause the e-commerce platform 105 to perform some of the processes and functions described herein. In some embodiments, the digital asset request controller 210 can be provided as a service external to the e-commerce platform 105. In particular, the e-commerce platform 105 can use the digital asset request controller 210 as a service that is independent of the e-commerce platform 105 and that facilitates processing requests related to the generation, sale, or transfer between entities associated with the e-commerce platform 105 of digital assets. More generally, in some implementations, the subject matter of the present application can be employed in a manner that is independent of a particular e-commerce platform. For example, the digital asset request controller 210 can be implemented and deployed independent of any e-commerce platform.

[0055] The digital asset request controller 210 is configured to receive requests to generate and / or transfer digital assets associated with the blockchain network 201. As will be described in greater detail below, the e-commerce platform 105 can be configured to facilitate the generation of digital assets based on a blockchain and the transfer of digital assets between merchants and customers and / or between customers. In particular, the digital asset transfer management engine 210 can enable the e-commerce platform 105 to perform various functions to implement the transfer of digital assets using a blockchain network.

[0056] While Figure 2 The digital asset request controller 210 of the e-commerce platform 105 is illustrated as a standalone component of the e-commerce platform 105, this is merely an example. The engine can also or instead be provided by another component that resides within the e-commerce platform 105 or external to the e-commerce platform. In some embodiments, the functions of the digital asset request controller 210 can be implemented within the commerce management engine 136. In some implementations, the digital asset transfer management engine 210 can be provided at least in part by the e-commerce platform, as a core function of the e-commerce platform, or as an application or service supported by or in communication with the e-commerce platform. Alternatively, the digital asset transfer management engine 210 can be implemented as a standalone service to a client such as a customer device or a merchant device. Additionally, at least a portion of such an engine can be implemented in a merchant device and / or a customer device. For example, a customer device can store and run the engine locally as a software application.

[0057] The data facility 134 can store data collected by the e-commerce platform 105 based on the interactions of merchants and customers with the e-commerce platform 105. For example, merchants provide data through their online sales activities. Examples of merchant data for a merchant include, but are not limited to, merchant identification information, product data for products (e.g., digital assets) offered for sale, online store settings, geographic regions for sales activities, historical sales data, and inventory locations. Customer data or data based on the interactions of customers and potential buyers with the e-commerce platform 105 can also be collected and stored in the data facility 134. Such customer data can be obtained based on inputs received via a customer device associated with a customer and / or potential buyer. By way of example, historical transaction event data including details of purchase transaction events by a customer on the e-commerce platform 105 can be recorded, and such transaction event data can be considered customer data. Such transaction event data can indicate product identifiers, date / time of purchase, final sale price, purchaser information including geographic region of the customer, and payment method details, among others. Other data regarding the use of the e-commerce platform 105 by merchants and customers (or potential buyers) can also be collected and stored in the data facility 134.

[0058] The data facility 134 can include customer preference data for customers of the e-commerce platform 105. For example, the data facility 134 can store account information, order history, browsing history, etc. for each customer that has an account associated with the e-commerce platform 105. The data facility 134 can additionally store wish list data and cart content data for one or more virtual shopping carts for multiple e-commerce accounts.

[0059] The digital asset request controller 210 is configured to receive requests related to digital assets from the user devices 230. In some cases, if the request is received from a user device 230 associated with a merchant account, the request can be a request to generate a digital asset. In some cases, if the request is received from a user device 230 associated with a buyer account or a customer account, the request can be a request to purchase a generated digital asset. In some cases, the request can be a request to transfer an existing digital asset from one owner address to another owner address, which can or can not be associated with a customer account on the e-commerce platform.

[0060] The received request can cause the digital asset request controller 210 to generate a blockchain transaction that is propagated on the blockchain network 201 that implements the request, whether the request is to generate a digital asset, transfer a digital asset, or otherwise perform an operation to manage a digital asset. In some cases, the blockchain transaction can be generated by the digital asset request controller 210 based on the request and can be provided to the user device 230 from which the request originated for cryptographic signature using a private key associated with an account associated with the request.

[0061] As noted above, congestion on the blockchain network 201 can result in higher transaction fees and / or greater latency, which is desirable when recording transactions on-chain. However, recording directly on-chain is preferred, particularly in cases where the NFTs can have associated significant value.

[0062] Accordingly, in one aspect, the present application provides a system and method for implementing digital asset operations that dynamically switch between layer 1 operations and layer 2 operations based on monitored blockchain network conditions. The system (e.g., digital asset request controller 210) determines a congestion metric with respect to the blockchain. If the congestion metric exceeds a first threshold level, the system can switch from using layer 1 transactions to process received requests to using layer 2 transactions to process received requests. Layer 2 transactions are used for a selected mechanism that collates and validates state at layer 1 and batch records transaction data periodically or occasionally records on-chain at layer 1. In some examples, the requests are executed at layer 2 by the digital asset request controller 210 to determine updated NFT state without using a corresponding function of the associated smart contract at layer 1, and the updated NFT state is periodically sent to the smart contract in a transaction that updates the NFT state at the smart contract, reflecting the completion of multiple layer 2 transactions. If the system determines that the monitored congestion metric is below a second threshold level (which can or can not be the same as the first threshold level), the system reverts to using layer 1 transactions to record received requests. In this way, the system is able to dynamically adapt to changing blockchain network congestion.

[0063] In some implementations, once the system determines that the congestion metric exceeds the first threshold level, any received requests related to digital asset operations (such as NFT minting or transfers) are saved in a queue. The queue can be a portion of memory that stores unrecorded requests for later batch processing. In some cases, the system can perform the operations related to the requests off-chain, such as recording the transfer operation or new ownership information in a separate ledger or network or system. Additionally or alternatively, the system can perform validation or verification operations while the requests are queued. Further, the system monitors for detection of a queue trigger. If a queue trigger is detected, the system batch processes the requests stored in the queue and updates the NFT state at layer 1 using a single blockchain transaction. The system can then clear the queue. When a request is next received, the system can reevaluate the congestion metric to determine whether to continue queuing received requests.

[0064] One of the queue triggers can be a determination that the congestion metric has dropped below the second threshold level. If this occurs, the system can process a batch transaction at layer 1 for any queued requests at that time, and then revert to using layer 1 transactions for processing without queuing any subsequently received requests.

[0065] Congestion metrics can include any one or more measurable indicators related to blockchain network congestion. In one example, a congestion metric can be a measure of transaction propagation rate, e.g., the number of new transactions received per second. In some examples, a congestion metric can be a count of unconfirmed transactions. In some examples, a congestion metric can be an average age of unconfirmed transactions (e.g., time since propagation / creation). In some cases, a congestion metric can be a rate of change (increase / decrease) in the number of unconfirmed transactions over a certain time window. In some examples, a congestion metric can be a secondary indicator of congestion, such as a transaction fee. A transaction fee can be a measure of current transaction fees on the network, such as an average transaction fee within one or more recently mined blocks. A congestion metric can be a gas price on an Ethereum network or other network that employs a metric to calculate a function cost. Various combinations of these measures can be combined, e.g., by linear, additive, and / or multiplicative combinations of one or more metrics or further combinations thereof, to derive a congestion metric. For example, the number or rate of unconfirmed transactions can be further weighted by a gas price per transaction to account for transactions that contain more complex operations. Additionally or alternatively, a congestion metric can not be directly one or more of the foregoing, but can be based on a value of one or more of the foregoing. For example, a raw value of one of the foregoing (or a combination thereof) can be scaled to fall within a certain defined range to yield a congestion metric.

[0066] In some cases, as an alternative or in addition to storing requests themselves, the queue stores (draft) transactions generated as a result of the received requests. The transactions are not propagated on the blockchain network, but are queued for batch processing by the system. Batch processing can include collating the transactions and / or transaction data into a single batch transaction that is propagated on the blockchain. In some cases, the queued “transactions” for queued requests are not fully compliant transactions according to the blockchain protocol, but contain sufficient data for the system to implement the requests by generating and propagating a correctly compliant batch transaction. In some implementations, the queued requests or transactions are processed by the digital asset request controller, and the resulting updated state / ledger is sent in a batch transaction.

[0067] In the case of NFTs, a layer 1 transaction call or invoke a function or other operation embedded in a smart contract stored on the blockchain, for example when generating an NFT, and in some cases when transferring an NFT. For example, a smart contract can provide a minting function that causes a blockchain virtual machine to perform operations to generate a unique NFT associated with a particular asset or other item. In some cases, a smart contract can include a transfer function to implement changes in the recordation of ownership of a particular NFT on the blockchain.

[0068] Batch transactions can contain multiple calls or events associated with two or more digital assets. In some implementations, queued requests (or data about those requests) are used as the basis for forming a batch transaction, which may include calls to multiple smart contract operations associated with the corresponding digital assets (e.g., NFTs). In some cases, the smart contract may contain code for processing multiple requests within the batch transaction. For example, the smart contract may implement a batch transfer function, which may include parameters or arguments for specifying the amount transferred, the transferor's address, the transferee's address, and the corresponding cryptographic signature. In another example, the smart contract may implement a batch minting function, which may include parameters or arguments for specifying the integer number of NFTs to be minted, the recipient's address, and the asset identifier. Each corresponding asset identifier may include a URI or other identifier for precisely locating the asset represented by the NFT. Batch functions can be configured to update the NFT state maintained by the smart contract to reflect the implementation of the queued transactions, wherein the updated state is determined by the digital asset request controller at Layer 2 outside the blockchain network. Other batch functions may also be defined in the smart contract.

[0069] In some cases, batch transaction processing functions reside in the same smart contract as regular transaction processing functions. In other cases, batch transaction processing functions reside in different smart contracts that are also deployed and logged on the blockchain.

[0070] To prevent malicious calls to batch functions, in some embodiments, smart contracts can restrict the availability or authorization of calls to batch functions to authorized entities. For example, a list of authorized IP addresses (also known as a "whitelist") defining where batch transactions must originate can be maintained. In some cases, oracles can maintain a whitelist or allowed list defining which entities or entities can use batch functions. The smart contract owner and / or their representative may have the authority to modify the allowed list.

[0071] Queue triggers can include one or more conditions or events that the system can detect. In some examples, a queue trigger can include the time elapsed since the first (oldest) request was stored in the queue, such as elapsed time. tseconds. In some examples, the queue trigger can be a determination that the number of queued requests exceeds a predetermined maximum count (i.e., a maximum number of requests in the queue). In some cases, the queue trigger can include a byte size of the queued requests and / or the queued transactions. In some cases, the queue trigger can be based on at least N requests having been received within a certain time period, e.g., a rate of requests being received. In some cases, the system can be configured to detect the queue trigger based on the maximum time elapsed or the maximum count, whichever comes first. As noted above, the queue trigger can be a determination that the congestion metric has fallen below a second threshold.

[0072] Referring now to Figure 3 FIG. 3 illustrates an example method 300 of processing a digital asset event request, in the form of a flow diagram. The method 300 can be implemented by a computing device having suitable computer-executable instructions for causing the computing device to perform the described operations. The method 300 can be implemented in whole or in part by a special-purpose computing device, such as a node of a blockchain network. In some cases, the method 300 can be implemented by a special-purpose module, engine, application, or other software component among a set of hardware components and software components for implementing an e-commerce platform. In some examples, the method 300 can be implemented by the digital asset request controller 210.

[0073] In operation 302, a transaction request is received. The transaction request relates to a digital asset. The digital asset can be associated with a physical asset or an online resource. In one example, the transaction request is a request to generate an NFT associated with an asset. In another example, the transaction request is a request to transfer ownership of an existing NFT associated with an asset. The request can include a digital signature of the owner or the requester. The request can include a reference to a particular blockchain smart contract associated with the NFT, and in some cases a reference to a particular function within the smart contract. The request can include an address associated with a recipient of the NFT.

[0074] In operation 304, a network congestion metric is measured or obtained. The congestion metric can include any one or more quantities or values related to blockchain network congestion. In one example, the congestion metric can be an indicator of transaction generation or propagation rate, e.g., a count of the number of new transactions received within a time window such as one second, five seconds, one minute, etc. In some examples, the congestion metric can be a current count of unconfirmed transactions, e.g., the number of pending transactions in a memory pool. In some examples, the congestion metric can be an average age of unconfirmed transactions, e.g., an average time since an unconfirmed transaction was received. In some cases, the congestion metric can be a rate of change in the number of unconfirmed transactions within a certain time window, e.g., a rate or speed at which unconfirmed transactions are increasing (whether positively or negatively). In some examples, the congestion metric can be a secondary indicator of network congestion such as how much or how many transaction fees. The transaction fee can be a measure of the current transaction fee on the network such as an average transaction fee within one or more recently mined blocks. The congestion metric can be a gas price on the Ethereum network or other blockchain network that employs a metric to calculate the cost of operations. Various sets or subsets of these measures can be combined to arrive at the congestion metric. As an example, the number or rate of unconfirmed transactions can be further weighted by the gas price per transaction to account for transactions that include more complex operations.

[0075] Once the congestion metric is obtained, it is compared to a first threshold level (as indicated by operation 306). The first threshold level can be selected or set based on the nature of the measured or obtained metric and based on the speed at which the method 300 is designed to switch to the layer 2 implementation. If the metric is below the first threshold level, the method 300 continues to operate at layer 1 and the received request causes a blockchain transaction to be generated and propagated to implement the request (as shown by operation 308). That is, a blockchain transaction is generated and output on the blockchain network. The blockchain transaction can include a reference to a smart contract or a function within a smart contract that, when executed, causes the network to perform the requested operation, e.g., generate an NFT or transfer NFT ownership, and record that state change on the blockchain.

[0076] The method 300 continues to operate in this manner, using layer 1 blockchain transaction processing for received requests, unless the congestion metric exceeds the first threshold level - in which case the method 300 proceeds to operation 310. In operation 310, the received request is appended to a queue. The queue can be a memory, or portion of memory, or data structure in a portion of memory designated to hold received requests to await batch processing.

[0077] In operation 312, a determination is made as to whether a queue trigger is detected. If not, the method 300 remains in a wait for a new request, as shown in operation 314, and then appends the new request to the queue while waiting for a queue trigger to be detected. The queue trigger can include one or more detectable conditions or events that result in batch processing of the contents of the queue. In one example, the queue trigger can include a maximum time since the first (e.g., oldest) request in the queue was queued. In another example, the queue trigger can include the number of queued requests reaching a maximum count (i.e., a maximum number of requests in the queue). In yet another example, the queue trigger can include the size of the queued requests and / or the size of the queued transactions, e.g., the number of bytes occupied by the queued requests or transactions. Multiple conditions or events can be specified as the queue trigger. For example, the queue trigger can be the maximum age of the oldest request or the maximum count of queued requests, whichever occurs first.

[0078] Another queue trigger can be detecting that the congestion metric has fallen below a second threshold level. In some cases, the second threshold level can be the same as the first threshold level. In some cases, the second threshold level can be lower than the first threshold level to prevent frequent switching when the congestion metric is at or near the threshold level.

[0079] The foregoing refers to queuing of received requests. In some implementations, the queue can include only a portion of the data from each received request. The portion of data would include such data as can be needed for formulating or generating a compliant blockchain transaction to implement the request. In some cases, the queue can contain draft blockchain transactions configured to implement the requests, rather than queued requests or request data. That is, the queue can contain a plurality of blockchain transactions in draft form. In another implementation, the system processes each request to update a locally maintained NFT state rather than queuing the requests, and the queue or storage stores the current NFT state as it is updated at the layer 2 as each “queued” request is received.

[0080] When a queue trigger is detected in operation 312, operation 316 assesses whether there is only a single request (or transaction) in the queue. This addresses a boundary condition where the queue trigger is detected after only a single request is queued. In this case, the method 300 can immediately revert to layer 1 operations and process the queued request in operation 308 as a normal course of a layer 1 blockchain transaction. Then, when the next request is received in operation 302, the method will assess whether the congestion metric is still worthy of using queued processing.

[0081] In the case where there is more than one queued request, then a “batch blockchain transaction” is generated in operation 318 and propagated on the blockchain network. The batch blockchain transaction implements more than one of the requests in the queue. In some cases, all of the requests in the queue are implemented in the batch blockchain transaction. In some cases, more than one batch blockchain transaction can be used to implement the requests. For example, in some implementations, NFT generation requests can be grouped together in one batch transaction, while NFT transfer requests can be grouped together in a different batch transaction, based on the fact that in some examples these two types of requests can reference different functions or portions of a smart contract or reference different smart contracts.

[0082] From a blockchain protocol perspective, the batch blockchain transaction is a single blockchain transaction. In that single blockchain transaction, two or more requests are contained and implemented.

[0083] In one example implementation, the batch blockchain transaction can include multiple calls to a smart contract function. In some cases, the batch blockchain transaction can include a call to a dedicated batch processing function in the smart contract, where the batch processing function receives parameters including: a count of requests and data for each included request. This can include, for example: a data structure containing NFT identifiers, a data structure containing asset identifiers, a data structure containing recipient address data, a data structure containing one or more digital signatures, and other such data. In some implementations, the batch blockchain transaction calls a custom NFT update function provided by the smart contract, and the batch blockchain transaction provides the updated NFT state resulting from processing all of the queued requests at layer 2.

[0084] Once the batch blockchain transaction is generated, it is propagated on the blockchain network. Once the batch blockchain transaction is included in a mined block by one of the blockchain mining nodes, the state changes resulting from the multiple queued requests are reflected in the data recorded on the blockchain. The NFT state or ledger maintained by the smart contract is updated to reflect the implementation of the multiple queued requests without the associated gas cost of invoking the smart contract code to execute each request as a smart contract operation.

[0085] Advantageously, the batch blockchain transaction can have a lower total fee and / or gas cost compared to the individual implementation of the requests in their own dedicated blockchain transaction. Moreover, by batching the requests into a batch transaction, the transaction can have a higher total transaction fee that will ensure that the batch transaction is mined quickly, whereas the individual transaction fee in each transaction can be too low (even if their sum is higher than the batch transaction fee) for miners to include these individual transactions in the candidate blocks they work on if the requests were in separate blockchain transactions. In this way, batching the requests into a batch transaction can result in the requests being executed and recorded more quickly in network congestion conditions, despite the inherent delay caused by queuing the requests in the first place. Additionally, by delaying the processing of the individual requests by queuing, in some cases the queue trigger is a congestion metric falling below a second threshold level, which can mean that when the batch blockchain transaction is generated and propagated as a result of the queue trigger, the blockchain network is operating under lower congestion and cost conditions, resulting in more efficient and cost-effective implementation of the requests.

[0086] Once all the requests in the queue have been processed in the batch blockchain transaction, the queue is cleared or emptied (as indicated by operation 320), and the method 300 resumes to operation 302 to wait for receiving a new request. When this new request is received, the congestion metric is again obtained and compared to the first threshold level to determine whether to handle the new request at the 1stlayer or to queue it for handling at the 2ndlayer.

[0087] Although the foregoing description refers to the generation or minting of NFTs and the transfer of NFTs as example requests, in some cases the requests can relate to other operations or events involving NFTs. In some other cases, the method and system can be implemented for requests relating to digital assets other than NFTs.

[0088] Example E-Commerce Platform

[0089] Although integration with a commerce platform is not necessary, in some embodiments the methods disclosed herein can be performed on or in association with a commerce platform such as an e-commerce platform. Accordingly, an example of a commerce platform will be described.

[0090] Figure 4 An e-commerce platform 100 according to one embodiment is illustrated. The e-commerce platform 100 can be the commerce platform 102 referred to with reference to Figure 2An example of an e-commerce platform 105 is described. The e-commerce platform 100 can be used to provide products and services of merchants to customers. While the present disclosure contemplates using devices, systems, and processes to purchase products and services, for simplicity the description herein will refer to products. All references to products in the present disclosure should also be understood to be references to products and / or services, including, for example, physical products, digital content (e.g., music, videos, games), software, tickets, subscriptions, services to be provided, etc.

[0091] While the present disclosure contemplates that “merchants” and “customers” can not only be individuals, for simplicity the description herein will generally refer to merchants and customers as individuals themselves. All references to merchants and customers in the present disclosure should also be understood to be references to groups of individuals, companies, businesses, computing entities, etc., and can represent for-profit or non-profit exchange of products. Further, while the present disclosure refers to “merchants” and “customers” throughout and describes their roles as individuals themselves, the e-commerce platform 100 should be understood to more generally support users in an e-commerce environment, and references to merchants and customers in the present disclosure should also be understood to be references to users, such as users that are merchant users (e.g., sellers, retailers, wholesalers, or product providers), customer users (e.g., buyers, purchasing agents, consumers, or product users), potential users (e.g., users that are browsing but have not yet committed to purchase, users that are evaluating the e-commerce platform 100 for potentially using to market and sell products, etc.), service provider users (e.g., shipping providers 112, financial providers, etc.), corporate or business users (e.g., corporate representatives that purchase, sell, or use products; business users; customer relationship or customer management agents, etc.), information technology users, computing entity users (e.g., computer bots for purchasing, selling, or using products), etc. Moreover, it can be recognized that while a given user can play a given role (e.g., as a merchant) in one context and their associated device can be referred to accordingly (e.g., as a merchant device), the same person can play a different role (e.g., as a customer) in another context and the same or another associated device can be referred to accordingly (e.g., as a customer device). For example, a person can be a merchant of one type of product (e.g., shoes) and a customer / consumer of another type of product (e.g., groceries). In another example, a person can be both a consumer and a merchant of the same type of product. In a particular example, a merchant engaged in transactions of a particular category of goods can act as a customer of the same category of goods when placing an order from a wholesaler (the wholesaler acting as the merchant).

[0092] The e-commerce platform 100 provides online services / facilities to merchants to manage their businesses. The facilities described herein are shown as part of the platform 100, but can also be configured in whole or in part separately from the platform 100, as a standalone service. Further, such facilities can additionally or alternatively be provided by one or more providers / entities in some embodiments.

[0093] In the example of FIG. 1, the platform 100 is configured to provide a variety of services / facilities to merchants, including the following: Figure 4 In the example of FIG. 1, the platform 100 is configured to provide a variety of services / facilities to merchants, including the following:

[0094] Online store 138 can represent a multi-tenant facility comprising a plurality of virtual storefronts. In embodiments, a merchant can configure and / or manage one or more storefronts in online store 138, such as through merchant device 102 (e.g., a computer, a laptop, a mobile computing device, etc.), and offer products to customers through a variety of different channels 110A-B (e.g., online store 138; application 142A-B; a physical location, through POS device 152; an electronic marketplace, such as through an electronic purchase button integrated into a website or social media channel, such as on a social network, a social media page, a social media messaging system). A merchant can sell across channels 110A-B and then manage their sales through e-commerce platform 100, where channels 110A can be provided as a facility or service internal or external to e-commerce platform 100. Additionally or alternatively, a merchant can sell at their physical retail store, at a pop-up shop, through wholesale, over the phone, etc. and then manage their sales through e-commerce platform 100. A merchant can employ all or any combination of these modes of operation. Notably, it can be possible that a merchant can improve sales probability and / or sales volume by employing various and / or particular combinations of these modes. In this disclosure, the terms “online store 138” and “storefront” can be used synonymously to refer to a merchant’s offering of online e-commerce services through e-commerce platform 100, where online store 138 can refer to a collection of storefronts supported by e-commerce platform 100 (e.g., for one or more merchants), or to a storefront of a single merchant (e.g., a merchant’s online store).

[0095] In some embodiments, a customer can interact with platform 100 through customer device 150 (e.g., a computer, a laptop, a mobile computing device, etc.), POS device 152 (e.g., a retail device, a self-service kiosk, an automated (self-service) checkout system, etc.), and / or any other commerce interface device known in the art. E-commerce platform 100 can enable a merchant to contact a customer through online store 138, through application 142A-B, through POS device 152 of a physical location (e.g., a storefront or other location of the merchant), communicate with a customer via electronic communication facility 129, etc., in order to provide a system for contacting a customer and facilitating merchant services for real or virtual paths available to contact a customer and interact with a customer.

[0096] In some embodiments, and as described further herein, the e-commerce platform 100 can be implemented by a processing facility. Such a processing facility can include a processor and a memory. The processor can be a hardware processor. The memory can be and / or can include a non-transitory computer-readable medium. The memory can be and / or can include random access memory (RAM) and / or persistent storage (e.g., magnetic storage). The processing facility can store (e.g., in the memory) a set of instructions that, when executed, cause the e-commerce platform 100 to perform e-commerce functions and support functions as described herein. The processing facility can be one or more of or can be part of a server, a client, a network infrastructure, a mobile computing platform, a cloud computing platform, a stationary computing platform, and / or other computing platform, and can provide electronic connectivity and communication between components of the e-commerce platform 100, merchant devices 102, payment gateways 106, applications 142A-B, channels 110A-B, shipping providers 112, customer devices 150, point-of-sale devices 152, and the like. In some implementations, the processing facility can be or can include one or more such computing devices working in concert. For example, a plurality of cooperating computing devices can be the / serve as / provide the processing facility. The e-commerce platform 100 can be implemented as or using one or more of a cloud computing service, a software as a service (SaaS), an infrastructure as a service (IaaS), a platform as a service (PaaS), a desktop as a service (DaaS), a management software as a service (MSaaS), a mobile backend as a service (MBaaS), an information technology management as a service (ITMaaS), and the like. For example, the underlying software implementing the facilities described herein (e.g., the online store 138) can be provided as a service and hosted centrally (e.g., then accessed by users through a web browser or other application, and / or accessed through customer devices 150, POS devices 152, and the like, over a network). In some embodiments, elements of the e-commerce platform 100 can be implemented to operate and / or integrate with various other platforms and operating systems.

[0097] In some embodiments, the facilities of the e-commerce platform 100 (e.g., the online store 138) can provide content to the customer devices 150, e.g., through a network connected to the e-commerce platform 100 (using the data 134). For example, the online store 138 can provide or send content in response to a request for the data 134 from a customer device 150, where a browser (or other application) is connected to the online store 138 through a network using a network communication protocol (e.g., an internet protocol). The content can be written in a machine-readable language and can include a hypertext markup language (HTML), a template language, JavaScript, and / or any combination thereof.

[0098] In some embodiments, the online store 138 can be or can include a service instance that provides content to a customer device and allows a customer to browse and purchase various available products (e.g., add products to a shopping cart, purchase through a purchase button, etc.). Merchants can also customize the look and feel of their website through a theme system, such as in which a merchant can choose and change the appearance of the merchant's online store 138 by showing the same underlying product and business data within the product information of the online store while changing their theme. It can be possible to further customize the theme through a theme editor (i.e., a design interface that enables a user to flexibly customize the design of their website). Additionally or alternatively, it can be possible to additionally or alternatively customize the theme using theme-specific settings, such as can change aspects of a given theme (e.g., specific colors, fonts, and pre-built layout schemes). In some implementations, the online store can implement a content management system for website content. Merchants can employ such a content management system when authoring blog posts or static pages and publishing them to their online store 138 (such as through a blog, article, login page, etc.), as well as configuring navigation menus. Merchants can upload images (e.g., products), videos, content, data, etc. to the e-commerce platform 100, such as for the system to store (e.g., as data 134). In some embodiments, the e-commerce platform 100 can provide functionality for manipulating such images and content, such as functionality for resizing images, associating images with products, adding text and associating text with images, adding images for new product variations, securing images, etc.

[0099] As described herein, the e-commerce platform 100 can provide sales and marketing services for products to merchants through a variety of different channels 110A-B, including, for example, the online store 138, the application 142A-B, and through the physical POS device 152, as described herein. The e-commerce platform 100 can additionally or alternatively include business support services 116 associated with operating an online business (such as providing one or more of domain registration services 118 associated with their online store, payment facilities 120 for facilitating transactions with customers, shipping services 122 for providing customer shipping options for purchased products, fulfillment services for managing inventory, risk and insurance services 124 associated with product protection and liability, merchant billing, etc.), administrators 114, warehouse management systems, etc. The services 116 can be provided via the e-commerce platform 100 or in association with external facilities, such as through a payment gateway 106 for payment processing, shipping providers 112 for expediting product shipping, etc.

[0100] In some embodiments, the e-commerce platform 100 can be configured with shipping services 122 (e.g., through e-commerce platform shipping facilities or through third-party carriers) to provide various shipping-related information to merchants and / or their customers, such as shipping labels or shipping information, real-time delivery updates, tracking, etc.

[0101] Figure 5 A non-limiting embodiment of the admin 114 is depicted. The admin 114 can be referred to as the management console and / or the admin console. The admin 114 can show information about daily tasks, recent activity for the store, and next steps the merchant can take to set up their business. In some embodiments, a merchant can log into the admin 114 via a merchant device 102 (e.g., a desktop computer or a mobile device) and manage aspects of their online store 138, such as viewing recent visit or order activity for the online store 138, updating the online store 138 catalog, managing orders, etc. In some embodiments, the merchant can be able to access different parts of the admin 114 by using a sidebar, such as the sidebar shown. Figure 5 The various parts of the admin 114 can include various interfaces for accessing and managing core aspects of the merchant’s business, including orders, products, customers, available reports, and discounts. The admin 114 can additionally or alternatively include interfaces for managing the merchant’s sales channels, including the online store 138, mobile application(s) (mobile App) that customers can use to access the store, POS devices, and / or buy buttons. The admin 114 can additionally or alternatively include interfaces for managing apps installed on the merchant’s account; and settings that apply to the merchant’s online store 138 and account. The merchant can use the search bar to find products, pages, or other information in their store.

[0102] More detailed information about the commerce and visitors to the merchant online store 138 can be viewed through reports or metrics. Reports can include, for example, traffic reports, behavior reports, customer reports, financial reports, marketing reports, sales reports, product reports, and custom reports. The merchant can be able to view sales data for different channels 110A-B for different time periods (e.g., days, weeks, months, etc.) such as by using a drop-down menu. Data overviews can also be provided for merchants who want to view sales and engagement data for their store in more detail. Activity feeds can be provided in the home page metrics section to show an overview of activity on the merchant account. For example, by clicking on the “See all recent activity” data panel button, the merchant can be able to see a recent activity feed on their account for a longer period of time. The home page can show notifications about the merchant’s online store 138 such as based on account status, growth, recent customer activity, order updates, etc. Notifications can be provided to help the merchant navigate through workflows configured for the online store 138 such as payment workflows, order fulfillment workflows, order archiving workflows, returns workflows, etc.

[0103] The e-commerce platform 100 can provide a communication facility 129 and associated merchant interface to provide electronic communications and marketing such as using an electronic messaging facility to collect and analyze communication interactions between merchants, customers, merchant devices 102, customer devices 150, POS devices 152, etc. to aggregate and analyze communications such as to improve sales conversions, etc. For example, a customer can have a product related question that can generate a conversation between the customer and the merchant (or an automated processor based agent / chatbot representing the merchant), in which case the communication facility 129 is configured to request that the customer provide an automated response and / or provide the merchant with suggestions on how to respond, for example, to improve the probability of a sale.

[0104] The e-commerce platform 100 can provide financial facilities 120 for secure financial transactions with customers, such as through a secure card server environment. For example, in a payment card industry data (PCI) environment (e.g., card server), the e-commerce platform 100 can store credit card information to reconcile finances, bill merchants, perform automated clearing house (ACH) transfers between the e-commerce platform 100 and a bank account of a merchant, etc. The financial facilities 120 can also provide financial support to merchants and buyers, such as through lending funds (e.g., loans, cash advances, etc.) and providing insurance. In some embodiments, the online store 138 can support multiple independently managed storefronts and process large amounts of transaction data for various products and services each day. The transaction data can include any customer information (e.g., contact information, billing information, shipping information, return / refund information, discount / promotion information, payment information) indicative of a customer, a customer account, or a transaction conducted by a customer or online store events or information (e.g., page views, product search information (search keywords, click events), product reviews, abandoned carts), and / or other transaction information associated with business conducted through the e-commerce platform 100. In some embodiments, the e-commerce platform 100 can store this data in the data facilities 134. Referring again to Figure 4 In some embodiments, the e-commerce platform 100 can include a commerce management engine 136, which can be configured to perform various workflows to automate tasks or content management related to products, inventory, customers, orders, vendors, reporting, finance, risk, and fraud, etc. In some embodiments, additional functionality can additionally or alternatively be provided through the application programs 142A-B to enable greater flexibility and customization needed to accommodate growing variety of online stores, POS devices, products, and / or services. The application programs 142A can be components of the e-commerce platform 100, while the application programs 142B can be provided or hosted as third-party services external to the e-commerce platform 100. The commerce management engine 136 can accommodate store-specific workflows, and in some embodiments, can incorporate the administrators 114 and / or the online stores 138.

[0105] Implementing functionality as application programs 142A-B can enable the commerce management engine 136 to remain responsive and reduce or avoid service degradation or more serious infrastructure failures, etc.

[0106] While isolating online store data can be important to maintain data privacy between online stores 138 and merchants, there can also be reasons to collect and use cross-store data, for example, for an order risk assessment system or a platform payment facility, both of which need information from multiple online stores 138 to perform well. In some embodiments, it can be preferable to move these components out of the commerce management engine 136 and into their own infrastructure within the e-commerce platform 100.

[0107] The platform payment facility 120 is an example of a component that leverages data from the commerce management engine 136 but is implemented as a separate component or service. The platform payment facility 120 can allow customers interacting with online stores 138 to have their payment information securely stored by the commerce management engine 136 so that the customers only have to enter their payment information once. When the customers visit different online stores 138, even if they have never been there before, the platform payment facility 120 can call up their information to enable faster and / or potentially less error-prone checkout (e.g., by avoiding situations where customers would otherwise need to re-enter their information where they can make mistakes in typing the information). This can provide a cross-platform network effect in which the e-commerce platform 100 becomes more useful to its merchants and buyers as more merchants and buyers join, such as because there are more customers more frequently checking out because of the ease of use for customers to purchase. To maximize the effect of this network, the payment information for a given customer can be made available and globally available across multiple online stores 138.

[0108] For functionality not included within the commerce management engine 136, the applications 142A-B provide a way to add features to the e-commerce platform 100 or individual online stores 138. For example, the applications 142A-B can be able to access and modify data on a merchant's online store 138, perform tasks through the administrator 114, implement new flows for merchants through a user interface (which is presented, for example, through an extension / API), etc. Merchants can be enabled to discover and install the applications 142A-B through the application search, recommendations, and support 128. In some embodiments, the commerce management engine 136, the applications 142A-B, and the administrator 114 can be developed to work together. For example, application extension points can be built into the commerce management engine 136, the applications 142A and 142B can access these application extension points through the interfaces 140B and 140A to provide additional functionality, and these application extension points can be presented to merchants in the user interface of the administrator 114.

[0109] In some embodiments, the applications 142A-B can provide functionality to the merchant through the interfaces 140A-B, such as the ability for the applications 142A-B to present transaction data to the merchant (e.g., App: “Engine, present my app data in the mobile app or in the admin 114”), and / or the commerce management engine 136 can request that the applications perform work on demand (Engine: “App, give me the local tax calculation for this checkout”).

[0110] The applications 142A-B can connect to the commerce management engine 136 through the interfaces 140A-B (e.g., through REST (Representational State Transfer) and / or GraphQL APIs) in order to expose the functionality of the commerce management engine 136 and the data available within the commerce management engine 136 to the functionality of the applications. For example, the e-commerce platform 100 can provide interfaces 140A-B for the applications 142A-B APIs that can connect to products and services outside of the platform 100. The flexibility provided by the use of applications and APIs, which is provided for application development, for example, enables the e-commerce platform 100 to better accommodate new and unique needs of merchants or to solve specific use cases without constantly changing the commerce management engine 136. For example, shipping services 122 can integrate with the commerce management engine 136 through shipping or carrier service APIs, enabling the e-commerce platform 100 to provide shipping service functionality without directly affecting the code running in the commerce management engine 136.

[0111] Depending on the implementation, the applications 142A-B can pull data on demand (e.g., customer creation events, product change events, or order cancellation events, etc.) or push data when updates occur using the APIs. A subscription model can be used to provide events to the applications 142A-B when they occur, or to provide updates about the changed state of the commerce management engine 136. In some embodiments, the commerce management engine 136 can publish a request, such as to a predefined callback URL, when a change related to an update event subscription occurs. The body of the request can contain the new state of the object and a description of the action or event. Update event subscriptions can be created manually in the admin facility 114 or automatically (e.g., via the APIs 140A-B). In some embodiments, update events can be queued and handled asynchronously from the state change that triggered the update event, which can result in update event notifications that are not distributed in real-time or near real-time.

[0112] In some embodiments, the e-commerce platform 100 can provide one or more of application search, recommendation, and support 128. The application search, recommendation, and support 128 can include: developer products and tools for aiding development of applications, application data panels (e.g., providing a development interface to developers, application management to administrators, application customization to merchants, etc.), facilities for installing and providing access to applications 142A-B (e.g., for public access, such as in cases where standards must be met prior to installation, or for private use by merchants), application search to make it easy for merchants to search for applications 142A-B that meet their needs for their online store 138, application recommendations to provide merchants with suggestions on how they can improve the user experience through their online store 138, etc. In some embodiments, the applications 142A-B can be assigned an application identifier (ID), such as for linking to the application (e.g., through an API), searching for the application, making application recommendations, etc.

[0113] The applications 142A-B can be broadly grouped into three categories: customer-facing applications, merchant-facing applications, integrated applications, etc. The customer-facing applications 142A-B can include online stores 138 or channels 110A-B, which are places where a merchant can list products for purchase (e.g., an online store, an application for flash sales (e.g., of merchant products or opportunistic sales opportunities from third-party sources), a mobile store application, a social media channel, an application for providing wholesale purchases, etc.). The merchant-facing applications 142A-B can include applications that allow a merchant to manage their online store 138 (e.g., through applications related to web or website or mobile device), run their business (e.g., through applications related to POS devices), grow their business (e.g., through applications related to shipping (e.g., drop shipping), using automated agents, using process flow development and improvement), etc. The integrated applications can include applications that provide useful integrations for participating in business operations, such as shipping providers 112 and payment gateways 106.

[0114] As such, the e-commerce platform 100 can be configured to provide an online shopping experience through a flexible system architecture that enables merchants to connect with customers in a flexible and transparent manner. A typical customer experience can be better understood through the example purchase workflow of an embodiment, in which a customer browses a merchant’s products on a channel 110A-B, adds products intended for purchase to a cart, checks out, and pays for the contents of the cart, thereby creating an order for the merchant. The merchant can then review and fulfill (or cancel) the order. The product is then shipped to the customer. If the customer is not satisfied, they can return the product to the merchant.

[0115] In example embodiments, a customer can browse a merchant's products through a number of different channels 110A-B, such as the merchant's online store 138; a physical storefront, through a POS device 152; an electronic marketplace, through an electronic purchase button integrated into a website or social media channel. In some cases, the channels 110A-B can be modeled as applications 142A-B. An expo component in the commerce management engine 136 can be configured to create and manage product listings (e.g., using product data objects or models) to allow a merchant to describe what they want to sell and where they want to sell it. The association between a product listing and a channel can be modeled as a product publication and accessed through a channel application (such as via a product listing API). A product can have a number of attributes and / or characteristics (such as size and color) and a number of variations that expand the available options to specific combinations of all attributes, such as a green variation with a size of extra small or a blue variation with a size of large. A product can have at least one variation created for the product without any options (e.g., a "default variation"). To facilitate browsing and management, products can be grouped into collections, products can be provided with product identifiers (e.g., stock keeping units (SKUs)), etc. Collections of products can be built by manually classifying products into a category (e.g., a curated collection), by building a ruleset for automatic classification (e.g., a smart collection), etc. A product listing can include a 2D image, a 3D image, or a model that can be viewed through a virtual reality or augmented reality interface, etc.

[0116] In some embodiments, a cart object is used to store or track products that a customer intends to purchase. The cart object can be channel-specific and can be composed of a number of cart order items, where each cart order item tracks the quantity of a specific product variation. Since adding a product to a cart does not imply any commitment from either the customer or the merchant, and the expected validity period of a cart can be on the order of minutes (rather than days), the cart object / data representing the cart can be persisted to a temporary data store.

[0117] The customer then proceeds to checkout. The checkout object or page generated by the commerce management engine 136 can be configured to receive customer information to complete the order, such as customer contact information, billing information, and / or shipping details. If the customer enters their contact information but does not proceed with payment, the e-commerce platform 100 can send a message to the customer device 150 (e.g., via the abandoned cart component) to encourage the customer to complete checkout. For these reasons, the checkout object can have a much longer validity period (hours or even days) than the cart object, and thus can persist. The customer then pays for the contents of their cart, creating an order for the merchant. In some embodiments, the commerce management engine 136 can be configured to communicate with various payment gateways 106 and services (e.g., online payment systems, mobile payment systems, digital wallets, credit card gateways) via a payment processing component. Actual interaction with the payment gateways 106 can be provided through a card server environment. An order is created at the end of the checkout process. An order is a sales contract between the merchant and the customer, in which the merchant agrees to provide the goods and services listed on the order (e.g., order items, shipping items, etc.) and the customer agrees to provide payment (including tax). Once an order is created, an order confirmation notification can be sent to the customer, and an order placement notification can be sent to the merchant via the notification component. When the payment processing job begins, inventory can be reserved to avoid overselling (e.g., the merchant can use inventory strategies or configurations for each variation to control this behavior). Inventory reservation can have a very short time span (minutes) and can need to be very fast and scalable to support flash sales or “drops,” during which discounted, promotional, or limited inventory of a product is offered for sale to buyers at a specific location and / or for a specific (usually short) period of time. If payment fails, the reservation is cancelled. After payment is successful and the order is created, the reservation is converted to a persistent (long-term) inventory commitment that is allocated to a specific location. The inventory component of the commerce management engine 136 can record the storage location of a variation and track the number of variations for which inventory tracking is enabled. This component can separate product variations (a customer-facing concept representing a product listing template) from inventory items (a merchant-facing concept representing items for which quantity and location are managed). The inventory level component can track quantities available for sale, committed to orders, or incoming from inventory transfer components (e.g., suppliers).

[0118] The merchant can then review and fulfill (or cancel) the order. The review component of the commerce management engine 136 can implement the business processes used by the merchant to ensure that the order is suitable for fulfillment before actually fulfilling the order. The order can be fraudulent, can require verification (e.g., ID check), can have a payment method that requires the merchant to wait to ensure they will receive their money, etc. Risks and recommendations can persist in the order risk model. Order risks can be generated by fraud detection tools, submitted by third parties through an order risk API, etc. Before fulfillment, the merchant can need to capture payment information (e.g., credit card information) or wait to receive payment information (e.g., via bank transfer, check, etc.) before marking the order as paid. Now, the merchant can prepare the product to be shipped. In some embodiments, this business process can be implemented by the fulfillment component of the commerce management engine 136. The fulfillment component can group the order items of an order into logical fulfillment work units based on inventory location and fulfillment services. The merchant can review, adjust the work units, and trigger the relevant fulfillment services, such as a manual fulfillment service used when the merchant picks the product and packs it into a box, purchases shipping labels and enters their tracking numbers (e.g., at a location managed by the merchant), or simply marks the items as fulfilled. Alternatively, an API fulfillment service can trigger third party applications or services to create fulfillment records for third party fulfillment services. Other possibilities exist for fulfilling an order. If the customer is not satisfied, they can return the product(s) to the merchant. The business process by which the merchant "cancels the sale" of the goods can be implemented by the return component. Returns can include a variety of different actions, such as: restocking, where the product that was once sold actually returns to the enterprise and can be sold again; refund, where some or all of the money taken from the customer is returned; accounting adjustment, where the amount of the refund is recorded (e.g., including whether there were any restocking fees, or whether the goods were not returned and remain with the customer); etc. A return can represent a change to a sales contract (e.g., order), and in this case, the e-commerce platform 100 can make the merchant aware of compliance issues regarding legal obligations (e.g., regarding taxes). In some embodiments, the e-commerce platform 100 can enable the merchant to track sales contracts over time, such as by implementing a sales model component (e.g., a date-based append-only ledger that records sales-related events that occur on the goods).

[0119] Embodiments

[0120] The methods and systems described herein can be deployed in part or in whole through a machine that executes computer software, program codes, and / or instructions on a processor. The processor can be part of a server, cloud server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform. The processor can be any kind of computational device or processing device capable of executing program instructions, codes, binary instructions, and the like. The processor can be or include a signal processor, digital processor, embedded processor, microprocessor or any variation thereof, such as a coprocessor (math co-processor, graphic co-processor, communication co-processor, and the like) that can directly or indirectly facilitate execution of program code or program instructions stored thereon. Further, the processor can implement multiple programs, threads, and codes. A thread can be part of a process or go beyond the scope of the process. A thread can be moved between processes or execution environments and can have a real time context, for example, a time-sharing context. With implementations, the methods, program codes, program instructions, and the like described herein can be implemented in one or more thread. The thread can cause another thread, which can have been allocated a priority associated therewith; a processor can execute these threads based on the priority or based on any other sequence according to the instructions provided in the program codes. The processor can include a memory that stores the methods, codes, instructions, and programs as described herein and elsewhere. The processor can access a storage medium that can store the methods, codes, and instructions as described herein and elsewhere through an interface. The storage medium associated with the processor for storing the methods, programs, codes, program instructions, or other types of instructions that the computational device or processing device is capable of executing can include, but is not limited to, one or more of a CD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache, and the like.

[0121] The processor can include one or more cores that can improve the speed and performance of the multi-processor. In some embodiments, the process can be a dual-core processor that combines two or more independent cores (referred to as a die), a quad-core processor, other chip-level multi-processor, and the like.

[0122] The methods and systems described herein can be deployed in part or in whole through a machine that executes computer software programs on a server, cloud server, client, firewall, gateway, hub, router, or other such computer and / or networking hardware. The software program can be associated with a server that can include a file server, print server, domain server, Internet server, intranet server and other variants such as secondary server, host server, distributed server and the like. The server can include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of facilitating communication with other servers, clients, machines and devices via wired or wireless medium. The methods, programs, or code described herein and elsewhere can be executed by the server. In addition, other devices required for executing the methods described in this application can be considered as a part of the infrastructure associated with the server.

[0123] The server can provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, such coupling and / or connection can facilitate remote execution of programs across the network. Some or all of these devices can be networked locally or remotely, and parallel processing of programs or methods can be facilitated via the network. In addition, any devices connected in the network to the server can include at least one storage medium adapted to store methods, programs, code and / or instructions. A central repository can provide program instructions to be executed on different devices. In such an implementation, the remote repository can serve as a storage medium for program code, instructions and programs.

[0124] The software program can be associated with a client that can include a file client, print client, domain client, Internet client, intranet client and other variants such as secondary client, host client, distributed client and the like. The client can include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of facilitating communication with other clients, servers, machines and devices via wired or wireless medium. The methods, programs, or code described herein and elsewhere can be executed by the client. In addition, other devices required for executing the methods described in this application can be considered as a part of the infrastructure associated with the client.

[0125] Clients can provide an interface to other devices including, but not limited to, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, such coupling and / or connection can facilitate remote execution of programs across the network. Some or all of these devices can be networked together, facilitating parallel processing of a program or method at one or more locations. Additionally, any devices connected via an interface to the client can include at least one storage medium capable of storing method, program, application, code, and / or instructions. A central repository can provide program instructions to be executed on different devices. In such embodiments, a remote repository can serve as a storage medium for program code, instructions, and programs.

[0126] The methods and systems described herein can be deployed partially or entirely through a network infrastructure. The network infrastructure can include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules, and / or components known in the art, among others. The computing and / or non-computing device(s) associated with the network infrastructure can include storage media such as, for example, flash memory, buffer, stack, RAM, ROM, etc., among others. The processes, methods, program codes, instructions described herein and elsewhere can be executed by one or more network infrastructure elements.

[0127] The methods, program codes, and instructions described herein and elsewhere can be implemented in different devices, which can operate in wired or wireless networks. Examples of wireless networks include 4th Generation (4G) networks such as Long Term Evolution (LTE) or 5th Generation (5G) networks, and non-cellular networks such as wireless local area networks (WLANs). However, the principles described herein can be equally applicable to other types of networks.

[0128] The operations, methods, program code, and instructions described herein and elsewhere can be implemented on or through mobile devices. Mobile devices may include navigation devices, cellular phones, mobile phones, mobile personal digital assistants, laptops, handheld computers, netbooks, pagers, e-book readers, music players, etc. Among other components, these devices may include storage media such as flash memory, buffers, RAM, ROM, etc., and one or more computing devices. The computing devices associated with the mobile device can be enabled to execute program code, methods, and instructions stored thereon. Alternatively, the mobile device may be configured to cooperate with other devices to execute instructions. The mobile device may communicate with a base station that interfaces with a server and is configured to execute program code. The mobile device may communicate on peer-to-peer networks, mesh networks, or other communication networks. Program code may be stored on storage media associated with the server and executed by a computing device embedded within the server. A base station may include computing devices and storage media. The storage device may store program code and instructions executed by the computing device associated with the base station.

[0129] Computer software, program code, and / or instructions can be stored and / or accessed on machine-readable media, which may include: computer components, devices, and recording media that retain digital data for computation over a period of time; semiconductor storage devices known as random access memory (RAM); mass storage devices typically used for more persistent storage, such as optical discs, magnetic storage forms (e.g., hard disks, magnetic tapes, magnetic drums, cards, and other types); processor registers, cache memory, volatile memory, and non-volatile memory; optical storage devices such as CDs and DVDs; removable media such as flash memory (e.g., USB flash drives or keys), floppy disks, magnetic tapes, paper tapes, punched cards, stand-alone RAM disks, Zip drives, removable mass storage devices, offline storage, etc.; and other computer memories such as dynamic memory, static memory, read / write storage devices, variable storage devices, read-only memory, random access memory, sequential access memory, location-addressable memory, file-addressable memory, content-addressable memory, network-attached storage devices, storage area networks, barcodes, magnetic ink, etc.

[0130] The methods and systems described in this paper can transform entities and / or intangible things from one state to another. The methods and systems described in this paper can also transform data representing entities and / or intangible things from one state to another, such as transforming usage data into a standardized usage dataset.

[0131] The elements described and depicted herein, including the elements in the flowcharts and block diagrams in all the drawings, imply logical boundaries between elements. However, according to software or hardware engineering practices, the depicted elements and their functionality can be implemented by computer executable media in a machine that executes program instructions stored on the computer executable media, which can be implemented as a single piece of software, as separate software modules, or as a combination of both, and that are stored on one or more computer readable storage media, and all such implementations are within the scope of the disclosure. Examples of such machines can include, but are not limited to, personal digital assistants, laptops, personal computers, mobile phones, other handheld computing devices, medical equipment, wired or wireless communication devices, transducers, chips, calculators, satellites, tablet PCs, electronic books, gadgets, electronic devices, devices with artificial intelligence, computing devices, networking devices, servers, routers, and the like. In addition, the depicted elements or any other logical component in the flowcharts and block diagrams can be implemented on a machine that executes program instructions. Therefore, although the flowcharts and block diagrams describe the disclosed system in a particular manner, the disclosure should not be construed to limited to these described arrangements. The software that implements the described functionality will vary depending upon the particular application, but such software should be self- describing. That is, the software should be readily understood by the programmers skilled in the art and needs no further explanation. Also, the steps of the processes described herein can be carried out in any order, unless otherwise specified or clearly implied to the contrary by the context in which the steps are described. Thus, the depicted order and grouping of steps should not be understood to require a particular order or grouping of steps, unless required by a particular application, or explicitly stated or clearly implied from the context.

[0132] The methods and / or processes described above, and steps thereof, can be implemented in hardware, software, or any combination of hardware and software suitable for a particular application. The hardware can include a general purpose computer and / or dedicated computing device or specific computing device or specific aspects or components of a specific computing device. The processes can be implemented in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, and internal and / or external memory. The processes can additionally or alternatively be implemented in an application specific integrated circuit, a programmable gate array, a programmable array logic, or any other device or combination of devices that can be configured to process electronic signals. It will further be appreciated that one or more of the processes can be implemented as computer-executable instructions on a machine-readable medium.

[0133] Computer-executable code can be in the form of software programming code contained in tangible, executable, linguistic instructions, such as assembly language, illustrative C, or higher-level language such as C++, and / or various other programming permutations, including interpreted instructions, scripts, microcode, byte code, firmware, parallel code, object code, super-compiled code, database queries, and / or any other programming language.

[0134] Accordingly, in an aspect, each of the methods described above and combinations thereof can be embodied in computer-executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods can be embodied in systems that execute the steps thereof and can be distributed across devices in a number of ways, or all of the functionality can be integrated into a dedicated, standalone device or other hardware. In another aspect, the apparatuses for performing the steps associated with the processes described above can include any of the hardware and / or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

[0135] The present teachings can also be extended to features of one or more of the following numbered clauses:

[0136] 1. A computer-implemented method comprising:

[0137] receiving a first non-fungible token transaction request;

[0138] obtaining a network congestion indicator regarding a congestion measure of a blockchain network;

[0139] determining that the network congestion indicator is above a first threshold level; and

[0140] in response to determining that the network congestion indicator is above the first threshold level,

[0141] queuing the first non-fungible token transaction request, and

[0142] detecting a queue trigger and, in response, generating and propagating a batch blockchain transaction on the blockchain network, the batch blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request.

[0143] 2. The method of clause 1, wherein the at least one additional non-fungible token transaction request is received after the first non-fungible token transaction request and is appended to a queue containing the first non-fungible token transaction request.

[0144] 3. The method of clause 1, wherein the network congestion indicator is based on one or more of: a count of unconfirmed transactions on the blockchain network, a rate of receipt of new transactions on the blockchain network, an average age of unconfirmed transactions on the blockchain network, a rate of change in the number of unconfirmed transactions over a certain time window, a cost metric for each computational operation, or a transaction fee.

[0145] 4. The method of clause 1, wherein detecting a queue trigger comprises one or more of: determining that a time elapsed since receiving the first non-fungible token transaction request has exceeded a maximum time, determining that a count of requests in the queue matches or exceeds a maximum count, or determining that the network congestion indicator has fallen below a second threshold level.

[0146] 5. The method of clause 4, wherein the second threshold level matches the first threshold level.

[0147] 6. The method of clause 1, wherein queuing comprises storing at least a portion of data from the first non-fungible token transaction request in a memory, the portion of data being sufficient to generate a blockchain transaction that implements the first non-fungible token transaction request.

[0148] 7. The method of clause 1, wherein the batch blockchain transaction references a batch processing function and provides an updated NFT state to reflect implementation of the two or more non-fungible token transaction requests.

[0149] 8. The method of clause 1, wherein the first non-fungible token transaction request is a minting request and includes a recipient address.

[0150] 9. The method of clause 8, wherein the at least one additional non-fungible token transaction request is another minting request and includes a respective recipient address.

[0151] 10. The method of clause 1, wherein the queued non-fungible token transaction requests include at least one transfer request for a previously minted token, and the at least one transfer request includes a transferee address and a digital signature.

[0152] 11. The method of clause 1, further comprising, after generating and propagating the batch blockchain transaction,

[0153] receiving a second non-fungible token transaction request;

[0154] obtaining an updated network congestion indicator for a congestion metric of the blockchain network;

[0155] determining that the updated network congestion indicator is below the first threshold level; and

[0156] in response to determining that the updated network congestion metric is below the first threshold level, generating and transmitting a single blockchain transaction on the blockchain network to implement the second non-fungible token transaction request individually without queuing.

[0157] 12. A computing system comprising:

[0158] a processor; and

[0159] a memory storing computer-executable instructions that, when executed by the processor, cause the processor to:

[0160] receive a first non-fungible token transaction request;

[0161] obtain a network congestion metric regarding a congestion measure of a blockchain network;

[0162] determine that the network congestion metric is above a first threshold level; and

[0163] in response to determining that the network congestion metric is above the first threshold level,

[0164] queue the first non-fungible token transaction request, and

[0165] detect a queue trigger and, in response, generate and propagate a batch blockchain transaction on the blockchain network, the batch blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request.

[0166] 13. The computing system of clause 12, wherein the at least one additional non-fungible token transaction request is received after the first non-fungible token transaction request and is appended to a queue containing the first non-fungible token transaction request.

[0167] 14. The computing system of clause 12, wherein the network congestion metric is based on one or more of: a count of unconfirmed transactions on the blockchain network, a rate of receipt of new transactions on the blockchain network, an average age of unconfirmed transactions on the blockchain network, a rate of change in the number of unconfirmed transactions over a window of time, a cost metric of each computing operation, or a transaction fee.

[0168] 15. The computing system of clause 12, wherein the instructions, when executed by the processor, cause the processor to detect a queue trigger by one or more of: determining that a time elapsed since receiving the first non-fungible token transaction request has exceeded a maximum time, determining that a count of requests in the queue matches or exceeds a maximum count, or determining that the network congestion metric has fallen below a second threshold level.

[0169] 16. The computing system of clause 15, wherein the second threshold level matches the first threshold level.

[0170] 17. The computing system of clause 12, wherein the instructions, when executed by the processor, cause the processor to queue by storing at least a portion of data from the first non-fungible token transaction request in the memory, the portion of data being sufficient to generate a blockchain transaction that implements the first non-fungible token transaction request.

[0171] 18. The computing system of clause 12, wherein the batch blockchain transaction references a batch processing function and provides an updated NFT state to reflect implementation of the two or more non-fungible token transaction requests.

[0172] 19. The computing system of clause 12, wherein the instructions, when executed by the processor, further cause the processor to, after generating and propagating the batch blockchain transaction,

[0173] receive a second non-fungible token transaction request;

[0174] obtain an updated network congestion indicator regarding a congestion measure of the blockchain network;

[0175] determine that the updated network congestion indicator is below the first threshold level; and

[0176] in response to determining that the updated network congestion indicator is below the first threshold level, generate and send a single blockchain transaction on the blockchain network to implement the second non-fungible token transaction request individually without queuing.

[0177] 20. A non-transitory computer-readable medium having stored computer- executable instructions that, when executed by a processor, cause the processor to:

[0178] receive a first non-fungible token transaction request;

[0179] obtain a network congestion indicator regarding a congestion measure of a blockchain network;

[0180] determine that the network congestion indicator is above a first threshold level; and

[0181] in response to determining that the network congestion indicator is above the first threshold level,

[0182] queue the first non-fungible token transaction request, and

[0183] detect the queue trigger and, in response, generate and propagate a bulk blockchain transaction on the blockchain network, the bulk blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request.

Claims

1. A computer-implemented method comprising: receiving a first non-fungible token transaction request; obtaining a network congestion indicator regarding a congestion measure of a blockchain network; determining that the network congestion indicator is above a first threshold level; and in response to determining that the network congestion indicator is above the first threshold level, queuing the first non-fungible token transaction request in a queue until a queue trigger is detected, the queue trigger comprising a determination that the network congestion indicator has fallen below a second threshold level; in response, generating and propagating a batch blockchain transaction on the blockchain network, the batch blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request; and after the non-fungible token transaction requests in the queue have been processed in the batch blockchain transaction, clearing the queue and waiting to receive new non-fungible token transaction requests.

2. The method of claim 1, wherein, the at least one additional non-fungible token transaction request is received after the first non-fungible token transaction request and is appended to the queue containing the first non-fungible token transaction request.

3. The method of claim 1, wherein, the network congestion indicator is based on one or more of a count of unconfirmed transactions on the blockchain network, a rate of receipt of new transactions on the blockchain network, an average age of unconfirmed transactions on the blockchain network, a rate of change in the number of unconfirmed transactions over a window of time, a cost measure of each computational operation, or a transaction fee.

4. The method of claim 1, wherein, detecting the queue trigger further comprises one or more of determining that a time elapsed since receiving the first non-fungible token transaction request has exceeded a maximum time or determining that a count of requests in the queue matches or exceeds a maximum count.

5. The method of claim 1, wherein, the second threshold level matches the first threshold level.

6. The method of claim 1, wherein, queuing comprises storing at least a portion of data from the first non-fungible token transaction request in a memory, the portion of data being sufficient to generate a blockchain transaction implementing the first non-fungible token transaction request.

7. The method of claim 1, wherein, the batch blockchain transaction references a batch processing function and provides an updated NFT state reflecting implementation of the two or more non-fungible token transaction requests.

8. The method of claim 1, wherein, the first non-fungible token transaction request is a minting request and includes a recipient address.

9. The method of claim 8, wherein, the at least one additional non-fungible token transaction request is another minting request and includes a respective recipient address.

10. The method of claim 1, wherein, the queued non-fungible token transaction requests include at least one transfer request regarding a previously minted token, and the at least one transfer request includes a transferee address and a digital signature.

11. The method of claim 1, further comprising, after generating and propagating the batch blockchain transaction, receiving a second non-fungible token transaction request; obtaining an updated network congestion indicator regarding a congestion measure of the blockchain network; determining that the updated network congestion indicator is below the first threshold level; and in response to determining that the updated network congestion indicator is below the first threshold level, generating and sending a single blockchain transaction on the blockchain network to implement the second non-fungible token transaction request individually without queuing.

12. A computing system comprising: a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the processor to: receive a first non-fungible token transaction request; obtain a network congestion indicator regarding a congestion measure of a blockchain network; determine that the network congestion indicator is above a first threshold level; and in response to determining that the network congestion indicator is above the first threshold level, queue the first non-fungible token transaction request in a queue until a queue trigger is detected, the queue trigger comprising a determination that the network congestion indicator has fallen below a second threshold level; in response, generate and propagate a batch blockchain transaction on the blockchain network, the batch blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request; and after the non-fungible token transaction requests in the queue have been processed in the batch blockchain transaction, clear the queue and wait to receive new non-fungible token transaction requests.

13. The computing system of claim 12, wherein, the at least one additional non-fungible token transaction request is received after the first non-fungible token transaction request and is appended to the queue containing the first non-fungible token transaction request.

14. The computing system of claim 12, wherein, the network congestion indicator is based on one or more of: a count of unconfirmed transactions on the blockchain network, a rate of receipt of new transactions on the blockchain network, an average age of unconfirmed transactions on the blockchain network, a rate of change in the number of unconfirmed transactions over a window of time, a cost measure of each computational operation, or a transaction fee.

15. The computing system of claim 12, wherein, the instructions, when executed by the processor, further cause the processor to detect the queue trigger by one or more of: determining that a time elapsed since receiving the first non-fungible token transaction request has exceeded a maximum time, or determining that a count of requests in the queue matches or exceeds a maximum count.

16. The computing system of claim 12, wherein, the second threshold level matches the first threshold level.

17. The computing system of claim 12, wherein, the instructions, when executed by the processor, cause the processor to queue by storing at least a portion of data from the first non-fungible token transaction request in the memory, the portion of data being sufficient to generate a blockchain transaction implementing the first non-fungible token transaction request.

18. The computing system of claim 12, wherein, the batch blockchain transaction references a batch processing function and provides an updated NFT state that reflects implementation of the two or more non-fungible token transaction requests.

19. The computing system of claim 12, wherein, the instructions, when executed by the processor, further cause the processor, after generating and propagating the batch blockchain transaction, receive a second non-fungible token transaction request; obtain an updated network congestion indicator regarding a congestion measure of the blockchain network; determine that the updated network congestion indicator is below the first threshold level; and in response to determining that the updated network congestion indicator is below the first threshold level, generate and send a single blockchain transaction on the blockchain network to implement the second non-fungible token transaction request individually without queuing. ​ 20. A non-transitory computer-readable medium having stored computer- executable instructions for, when executed by a processor: receiving a first non-fungible token transaction request; obtaining a network congestion indicator regarding a congestion measure of a blockchain network; determining that the network congestion indicator is above a first threshold level; and in response to determining that the network congestion indicator is above the first threshold level, queuing the first non-fungible token transaction request in a queue until a queue trigger is detected, the queue trigger comprising a determination that the network congestion indicator has fallen below a second threshold level; in response, generating and propagating a batch blockchain transaction on the blockchain network, the batch blockchain transaction implementing two or more queued non-fungible token transaction requests, including the first non-fungible token transaction request and at least one additional non-fungible token transaction request; and after the non-fungible token transaction requests in the queue have been processed in the batch blockchain transaction, clearing the queue and waiting to receive new non-fungible token transaction requests.

Images