WO2024055103A1 - Système et procédé d'indexation de transactions de chaîne de blocs - Google Patents

Système et procédé d'indexation de transactions de chaîne de blocs Download PDF

Info

Publication number
WO2024055103A1
WO2024055103A1 PCT/CA2023/051201 CA2023051201W WO2024055103A1 WO 2024055103 A1 WO2024055103 A1 WO 2024055103A1 CA 2023051201 W CA2023051201 W CA 2023051201W WO 2024055103 A1 WO2024055103 A1 WO 2024055103A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
blockchain
transactions
user
address
Prior art date
Application number
PCT/CA2023/051201
Other languages
English (en)
Inventor
Mathieu BARIL
Luc BLACKBURN
Original Assignee
Laboratoires Octav Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Laboratoires Octav Inc. filed Critical Laboratoires Octav Inc.
Publication of WO2024055103A1 publication Critical patent/WO2024055103A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • the technical field generally relates to blockchain indexing techniques, and more particularly relates to systems and methods for indexing blockchain transactions associated with a blockchain address.
  • the crypto asset and blockchain ecosystem is continuously growing and has more and more opportunities for investors to acquire new assets via new platforms.
  • the decentralization and variability of crypto assets and platforms make it difficult for investors to have a global overview of their asset portfolio. Since different assets and platforms are disjointed from one another, it is a challenge to aggregate and keep track of relevant information to allow investors to make informed decisions relating to their portfolio.
  • a computer-implemented method for indexing blockchain transactions associated with a user-provided blockchain address includes requesting, from a plurality of blockchain networks, transactions associated with the user-provided blockchain address; receiving the transactions. For each of the transactions, the method includes determining a blockchain network associated with the transaction; determining a predicted blockchain protocol associated with the transaction based on a source or a destination address of the transaction, the predicted blockchain protocol being determined using a global database of a back-end server, the global database providing a mapping between blockchain addresses and blockchain protocols; determining a predicted transaction type associated with the transaction based on characteristics of the transactions, the predicted transaction type being determined using the global database, the global database further providing a mapping between transaction characteristics and transaction types; calculating a financial position of the blockchain address using the transaction based on the blockchain network, the predicted blockchain protocol, and the predicted transaction type associated with the transaction; presenting to a user, via a user device, the predicted blockchain protocol and the predicted transaction type, and soliciting an input from the user to confirm or
  • the user modifying the predicted blockchain protocol or predicted transaction type causes a confirmed blockchain protocol and transaction type to be stored in a user-specific database, and causes the financial position of the blockchain address to be recalculated based on the confirmed blockchain protocol and confirmed transaction type.
  • the user modifications to the predicted blockchain protocol or predicted transaction type are transmitted to the back- end server, the back-end server using the user modifications to update the global database, thereby allowing for more accurate determinations of predicted blockchain protocols and predicted transaction types for future transactions.
  • non-transitory computer-readable medium has instructions stored thereon which, when executed by a processor of one or more computing systems cause the one or more computing systems to carry out the method as described above.
  • a system for indexing blockchain transactions associated with a user-provided blockchain address includes a global database storing a mapping between blockchain addresses and blockchain protocols; a user-specific database storing user-confirmed blockchain protocols and transaction types associated with blockchain transactions; a front-end module for soliciting input from a user via a user device; and a back-end module in operative communication with the global database, user-specific database and front-end module.
  • the back-end module is configured to: request, from a plurality of blockchain networks, transactions associated with the user-provided blockchain address; receive the transactions, and for each of the transactions: determine a blockchain network associated with the transaction; determine a predicted blockchain protocol associated with the transaction based on a source or a destination address of the transaction, the predicted blockchain protocol being determined using the global database; determine a predicted transaction type associated with the transaction based on characteristics of the transactions, the predicted transaction type being determined using the global database; calculate a financial position of the blockchain address using the transaction based on the blockchain network, the predicted blockchain protocol, and the predicted transaction type associated with the transaction; presenting to the user, via the front-end module, the predicted blockchain protocol and the predicted transaction type, and soliciting an input from the user to confirm or modify the predicted blockchain protocol and the predicted transaction type.
  • the back-end module is configured to: store the confirmed blockchain protocol and transaction type in the user-specific database, and cause the financial position of the blockchain address to be recalculated based on the confirmed blockchain protocol and confirmed transaction type; and update the mappings in the global database based on the user input, thereby allowing for more accurate determinations of predicted blockchain protocols and predicted transaction types for future transactions.
  • a method for indexing blockchain transactions associated with a blockchain address includes: requesting, from a blockchain network, transactions associated with the blockchain address; receiving the transactions from the blockchain network; and for each of the transactions: predicting a blockchain protocol associated with the transaction based on a source address or a destination address of the transaction by querying a global database; predicting a transaction type associated with the transaction based on at least one characteristic of the transaction by querying the global database; and calculating a financial position of the transaction based on the blockchain protocol and the transaction type associated with the transaction.
  • a non-transitory computer-readable medium has instructions stored thereon which, when executed by one or more processors of a computing system, cause the computing system to carry out a method for indexing blockchain transactions associated with a blockchain address, including: requesting, from a blockchain network, transactions associated with the blockchain address; receiving the transactions from the blockchain network; and for each of the transactions: predicting a blockchain protocol associated with the transaction based on a source address or a destination address of the transaction by querying a global database; predicting a transaction type associated with the transaction based on at least one characteristic of the transaction by querying the global database; and calculating a financial position of the transaction based on the blockchain protocol and the transaction type associated with the transaction.
  • a system for indexing blockchain transactions associated with a blockchain address includes: a global database storing a mapping between blockchain addresses and blockchain protocols, and storing a mapping between transaction characteristics and transaction types; and a back-end module in operative communication with the global database, the back-end module being configured to: request, from a blockchain network, transactions associated with the blockchain address; receive the transactions from the blockchain network; and for each of the transactions: predict a blockchain protocol associated with the transaction based on a source address or a destination address of the transaction by querying the global database; predict a transaction type associated with the transaction based on at least one characteristic of the transaction by querying the global database; and calculate a financial position of the transaction based on the blockchain protocol and the transaction type associated with the transaction.
  • Figure 1 is a block diagram illustrating a system for indexing blockchain transactions, according to an embodiment.
  • Figure 2 is a flowchart illustrating a method for indexing blockchain transactions, according to an embodiment.
  • Figures 3A and 3B are flowcharts illustrating validation mechanisms applied in the method illustrated in Figure 2, according to possible embodiments.
  • FIGS 4-10 are schematics illustrating screens of a graphical user interface (GUI) for display on a user device in the system of Figure 1 , according to an embodiment.
  • GUI graphical user interface
  • connection and “coupled”, and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements.
  • the expression “based on” is intended to mean “based at least partly on”, that is, this expression can mean “based solely on” or “based partially on”, and so should not be interpreted in a limited manner. More particularly, the expression based on” could also be understood as meaning “depending on”, “representative of”, indicative of”, “associated with” or similar expressions.
  • blockchain transaction refers to a transaction between a first address and a second address recorded on a given blockchain network. For instance, a crypto asset exchange between a source address (i.e., the first address) and a destination address (i.e. , the second address) within the blockchain.
  • a “crypto asset”, herein, refers to a digital asset that uses cryptography, peer-to- peer networks and distributed ledger technologies (such as a blockchain) to create, validate and secure a blockchain transaction.
  • Crypto assets can have a variety of characteristics and be used as a medium of exchange or storage of assets.
  • the crypto asset can be in the form of a token, such as Ethereum and bitcoin, or a non- fungible token (NFT), as examples only.
  • NFT non- fungible token
  • blockchain address refers to a string of characters (i.e., alphanumerical for example) that represents an entity (such as a user, a crypto asset project, and the like) adapted to send and receive crypto assets.
  • entity such as a user, a crypto asset project, and the like
  • the blockchain address is unique.
  • blockchain network refers to a distributed database or ledger (i.e., distributed ledger) that is shared among nodes of a computer network (or distributed among computing devices of a network).
  • the blockchain network is adapted to maintain a secure and decentralized record of transactions.
  • a “blockchain protocol” refers to a set of rules that govern or characterize a blockchain address.
  • the blockchain protocol refers to rules that an entity must respect (i.e., a user) in order to communicate with the blockchain address.
  • the blockchain protocol uses the blockchain network as a base architecture to allow communication between entities and the blockchain address.
  • examples of blockchain protocols can be, but not limited to, MakerDAO, Lido, AAVE, Uniswap, Curve, Convex, PancakeSwap, Compound, and Instadapp. It should be noted that, the blockchain protocol can be bound to a set of rules stored, for instance, in a smart contract. Referring to Figure 1 , there is illustrated an embodiment of a system 10 for indexing blockchain transactions.
  • the system 10 includes a computing platform 100 configured to communicate with external components.
  • the computing platform can be configured to communicate with user devices 20 and a plurality of blockchain networks 50.
  • User devices 20 can correspond to any device operable by users to interact with computing platform 100, such as a personal computer 20a or smartphone 20b, among others.
  • the computing platform 100 includes a front-end module 110, a back-end module 120, a global database 130 and a user-specific database 140.
  • the front-end module 110 is configured to allow users to interact with the computing platform 100.
  • the front-end module 110 includes a front-end server (such as a single server or cluster of servers) providing a web page accessible via user devices such as a personal computer 20a or smartphone 20b (e.g., by accessing the page via a web browser).
  • a front-end server such as a single server or cluster of servers
  • the front-end module 110 can include a native software component running on user devices 20a, 20b.
  • the front-end module 110 can be configured to receive user input from the user devices 20a, 20b and to communicate such input with other components of the computing platform 100.
  • the back-end module 120 can be configured to communicate with the plurality of blockchain networks 50 to request blockchain transactions therefrom. By communicating with the blockchain networks 50, it is understood that the back-end module 120 is configured to connect to each of the plurality of blockchain networks 50 and query at least one node 55 of each blockchain network 50 to receive blocks and/or extract blockchain transactions therefrom.
  • the back-end module 120 can be configured to connect to various blockchain networks 50 utilising the Ethereum Virtual Machine (EVM) technology, such as, but not limited to, Ethereum, Binance Smart Chain, Avalanche, Arbitrum, Optimism, Polygon and Fantom. It is appreciated, however, that in other embodiments, the back-end module 120 can also be configured to communicate with other blockchain networks such as Bitcoin, Solana and Cosmos, among others.
  • EVM Ethereum Virtual Machine
  • the back-end module 120 can be further configured to index blockchain transactions received from the plurality of blockchain networks 50. As it will be described in more detail hereinbelow, indexing the blockchain transactions can involve identifying a blockchain network, a blockchain protocol, and a transaction type associated with each transaction, such that a value associated with the transaction can be determined. In some embodiments, the indexing of the blockchain transactions can be carried out at least in part using user input received from the front-end module 110.
  • the back-end module 120 can also be configured to transmit data related to blockchain transactions and/or indexed blockchain transactions to the front-end module 110.
  • the back-end module 120 includes a back-end server (such as a single server or cluster of servers) in communication with the front-end module 110, such as a front-end server. It is appreciated, however, that other configurations are possible. For example, in some embodiments, the front-end module 110 and backendmodule 120 can be implemented on the same server or cluster of servers.
  • the global database 130 includes persistent storage accessible via the back-end module 120, and can be configured to store general information related to blockchain transactions and blockchain networks 50. For instance, the global database 130 can maintain general information about blockchain protocols, types of blockchain transactions and other characteristics related to a transaction which can be used by the back-end module 120 to identify blockchain protocols and transaction types associated with a given blockchain transaction.
  • the blockchain protocols and types of blockchain transaction stored in the global database can be derived from blockchain transactions previously indexed by the back-end module 120. In some embodiments, the blockchain protocols and transaction types stored in the global database 130 can be entered manually, for instance, by a user or administrator directly having access to modify the content of the global database 130.
  • the user-specific database 140 includes persistent storage accessible via the back-end module 120, and can be configured to store user-specific information related to blockchain transactions and blockchain networks 50.
  • the user-specific database 140 can be configured to maintain user-provided modifications to indexed blockchain transactions (e.g., received via a user input) that can impact the value associated with the blockchain transactions.
  • the modified transaction type can be stored in the user-specific database 140 in association with said blockchain transaction to override the transaction type determined by the back-end module 120.
  • the method involves indexing blockchain transactions associated with a blockchain address to determine values associated with such blockchain transactions, and aggregating the determined values to establish a trading position associated with the blockchain address which can be displayed in a dashboard.
  • a first step 210 of the method 200 can include receiving, via the back-end module 120, a blockchain transaction associated with a blockchain address.
  • the blockchain transaction can, for example, be received following a request for blockchain transactions from the plurality of blockchain networks 50.
  • requesting blockchain transactions can be carried out in different ways.
  • each of the plurality of blockchain networks 50 can be queried for transactions associated with a given blockchain address (such as a wallet address).
  • the blockchain address can be a user-provided address received by the front-end module 110, for example via an input received via user device 20. The user-provided address can then be communicated to the back-end module 120 which can query the blockchain networks 50 using the user-provided blockchain address.
  • the input received via user device 20 can correspond to a human-readable name associated with a blockchain address via a name service, such as the Ethereum name service.
  • the human-readable name can be submitted to the name service to retrieve the blockchain address associated with the human-readable name prior to querying the blockchain networks 50.
  • Requesting blockchain transactions can include connecting to a node 55 of a blockchain network and receiving therefrom blockchain transactions associated with the blockchain address on that blockchain network. More specifically, a plurality of blockchain transactions can be received from the node 55, and those transactions can be filtered to retain only those involving the blockchain address. The process can be repeated for each blockchain network in the plurality of blockchain networks 50.
  • the back-end module 120 is configured to communicate directly with the nodes 55 of the plurality of blockchain networks 50 to receive transactions therefrom. It is appreciated, however, that other configurations are possible.
  • the back-end module 120 can be configured to communicate with a service that is capable of scanning the plurality of blockchain networks 50 (such as a blockchain explorer) and request blockchain transactions involving the blockchain address via an Application Programming Interface (API) call.
  • API Application Programming Interface
  • the requesting of blockchain transactions can be carried out by the front-end module 110, and the transactions can then be provided to the back-end module 120 for subsequent indexing.
  • the requesting of blockchain transactions can be performed each time a user logs into the computing platform 100 and/or following a refresh command received via the user device 20.
  • the back-end module 120 can be configured to receive only new transactions that have occurred since a previous request. For example, before connecting to a blockchain network to request transactions therefrom, the back-end module 120 can be configured to identify a block of the blockchain network corresponding to the last received transaction associated with the blockchain address. The back-end module 120 can then request from the blockchain network only transactions that occurred after the identified block. It is appreciated, however, that other configurations are possible. For example, in some embodiments, the back-end module 120 can receive all blockchain transactions associated with the blockchain address, and filter those transactions to retain only those that have not yet been indexed.
  • a subsequent step 220 can include determining, via the back-end module 120, a blockchain network associated with the blockchain transaction.
  • the blockchain network can be determined implicitly as part of step 210, since when a blockchain network is queried, the association between that blockchain network and the received transactions is known.
  • subsequent steps can include predicting parameters associated with the blockchain transaction via the back-end module 120.
  • a first parameter is predicted by the back-end module 120 in step 230.
  • the first parameter corresponds to a prediction of the blockchain protocol that was likely used to carry out the blockchain transaction on the determined blockchain network.
  • the blockchain protocol can, for example correspond to MakerDAO, Lido, AAVE, Uniswap, Curve, Convex, PancakeSwap, Compound, Instadapp, among others.
  • the blockchain protocol associated with the blockchain transaction can be predicted using different techniques.
  • the back-end module 120 is configured to predict the blockchain protocol based on a source address and/or a destination address involved in the blockchain transaction. More specifically, the back-end module 120 is configured to consult (i.e. , query or make a request to) the global database 130 which stores a mapping between addresses and blockchain protocols (also referred to as a protocol filter). The back-end module 120 can determine whether the source address and/or destination address match an address associated with a blockchain protocol maintained in the global database 130, and thus the back-end module 120 can determine if either one of the addresses corresponds to a known blockchain protocol maintained in the global database 130. As can be appreciated, a given blockchain transaction can include a plurality of source and/or destination addresses.
  • the protocol can be predicted by matching at least one of the plurality of source and/or destination addresses with an address mapped in the global database 130.
  • the back-end module 120 can also query user-specific database 140 which stores user-defined preferences comprising mappings between addresses and blockchain protocols that take precedence over the mappings in the global database 130.
  • a transaction may include a source address corresponding to a blockchain address associated with a wallet, and a destination address corresponding to a blockchain address associated with a blockchain protocol such as Uniswap.
  • the blockchain address of Uniswap can be well known, and the mapping between Uniswap and the known address can be stored as part of the protocol filter in global database 130.
  • the back-end module 120 can predict that the blockchain protocol corresponds to Uniswap by identifying a match between the destination address of the transaction and the address associated with the Uniswap protocol as stored in the global database 130. As can be appreciated, a similar matching can be carried out to predict other blockchain protocols mapped in the global database 130.
  • the blockchain protocol can correspond to a wallet protocol, for example where the transaction corresponds to a transfer between two blockchain wallets.
  • the back-end module 120 can predict that the blockchain protocol corresponds to a wallet protocol if both the source and destination addresses are mapped to wallets in the global database 130.
  • an explicit mapping between a given blockchain address and a specific blockchain protocol may not be stored in the global database 130.
  • the given blockchain address can be mapped as being a wallet by default.
  • the back-end module 120 can be configured to predict that the blockchain protocol corresponds to a wallet protocol by default if the global database 130 does not store an explicit mapping for both the source and destination addresses involved in the transaction.
  • the prediction of the blockchain protocol can be improved by allowing the global database 130 to be regularly updated and/or modified, for example to allow adding new blockchain protocols and/or correcting the mapping of existing blockchain protocols.
  • the computing platform 100 can be configured to allow users to suggest which blockchain protocol the blockchain address should be mapped to.
  • the computing platform 100 can be configured to allow users to suggest a correction to the mapping.
  • an open-source file can be made available allowing users to propose adding blockchain addresses associated with new blockchain protocols or editing existing relationships between blockchain addresses and known blockchain protocols.
  • the open-source file can be made available via the frontend module 110.
  • proposals submitted in the open-source file can be reviewed by at least one administrator of the computing platform 100 or even by the back-end module 120 before being added to the global database 130.
  • other means can be provided for allowing additions and/or modifications to mappings stored in the global database 130, as will be described in more detail hereinbelow.
  • a second parameter of the blockchain transaction is predicted by the back-end module 120 in step 240.
  • the second parameter corresponds to a predicted transaction type associated with the blockchain transaction.
  • the predicted transaction type can correspond to a type of transaction that was carried using the predicted blockchain protocol, such as Airdrop, Approval, Borrow, Claim, Failed, Ignore, Interaction, Transfer In, Transfer Out, Spam, Wrap, Unwrap, Withdraw, Bridge, Deposit, among others.
  • the transaction type can be predicted using different techniques.
  • the back-end module 120 is configured to predict the transaction type that has been performed based on characteristics associated with the blockchain transaction.
  • one characteristic associated with the blockchain transaction can be the blockchain protocol used to carry out the transaction.
  • the back-end module 120 can be configured to predict the transaction type based at least in part on the previously predicted blockchain protocol (i.e. , as predicted at step 230). For instance, the transaction type can be determined if the source or destination address is associated with a known blockchain protocol that is used specifically for a given type of transaction. For example, previously mentioned Uniswap is a blockchain protocol most commonly used to swap (or exchange) crypto assets. The back-end module 120 can therefore be configured to determine that a blockchain transaction whose source or destination address matches the Uniswap address is likely a swap.
  • the back-end module 120 can be configured to predict a transaction type based on other protocols and source or destination addresses associated with a particular transaction type implemented by that protocol. It should be noted that predicting the type of transaction is not limited to the blockchain protocol used for the transaction and that other characteristics associated with the transaction can be taken into account as well.
  • Another characteristic associated with the blockchain transaction can be patterns in the inputs and/or outputs of the blockchain transaction.
  • the back-end module 120 can be configured to predict the transaction type based at least in part on patterns of the source and/or destination addresses involved in the transaction.
  • Such patterns of addresses can indicate the provenance of crypto assets and what is done with them as part of a transaction.
  • an incoming crypto asset transferred into a wallet i.e., the destination address corresponds to a wallet
  • an outgoing crypto asset transferred out of a wallet i.e., the source address corresponds to a wallet
  • a further characteristic associated with the blockchain transaction can be smart contracts involved in the blockchain transaction and/or functions of smart contracts used by the blockchain transaction.
  • the back-end module 120 can be configured to predict the transaction type based at least in part on a specific smart contract involved in the transaction and/or based on a specific function of a smart contract used by or invoked as part of the transaction.
  • it can be determined that a smart contract is involved in a transaction by determining that the source or destination address of the transaction corresponds to an address associated with a known smart contract.
  • a smart contract function used by the transaction can be determined by analyzing the data field of the blockchain transaction and identifying a function selector contained therein.
  • the data field can be further analyzed to identify arguments provided to the smart contract function.
  • the back-end module 120 can predict that the transaction type likely corresponding to staking.
  • Other transaction types can be predicted according to other known smart contracts and known functions that they implement.
  • the back-end module 120 can be configured to consult (i.e. , query or make a request to) the global database 130 which stores a mapping between characteristics of blockchain transactions and different transaction types (also referred to as a transaction type filter).
  • the global database 130 can store mappings between blockchain addresses associated with particular blockchain protocols and corresponding transaction types, and/or between input and/or output patterns of blockchain transactions and corresponding transaction types.
  • the global database 130 can store mappings between smart contracts and/or smart contract functions and corresponding transaction types.
  • the Application Binary Interface (ABI) of smart contracts can be processed to extract function signatures therefrom, and the global database 130 can maintain a mapping between function signatures and corresponding transaction types.
  • ABSI Application Binary Interface
  • the back-end module 120 can also query user-specific database 140 which stores user- defined preferences comprising mappings between characteristics of blockchain transactions and different transaction types that take precedence over the mappings in the global database 130.
  • the back-end module 120 can be configured to utilize mappings of more than one blockchain transaction characteristic in order to make a prediction about the type of transaction. For example, in cases where a blockchain protocol can be associated with more than one transaction type, mappings of other transaction characteristics can be used to refine which specific transaction type should apply.
  • the global database 130 can also be configured to map different characteristics to each other to determine the transaction type. For example, a blockchain transaction with known patterns can be associated with a particular transaction type.
  • the back-end module 120 can be configured to determine a suggested value of the blockchain transaction by calculating a financial position of the blockchain transaction.
  • the back-end module 120 can calculate the financial position based on the previously predicted information such as the blockchain network, the predicted blockchain protocol and the predicted transaction type. More specifically, in the present configuration, different accounting techniques can be applied based on the different combinations of previously predicted information. Examples of accounting techniques can include calculating the cost basis of a newly acquired crypto asset based on the price at the moment of its acquisition. For instance, the back-end module 120 can be configured to query the price of the newly acquired asset via external APIs and calculate the cost basis by deriving the total balance acquired and the price of acquisition.
  • the back-end module 120 can be configured to calculate the profit or loss resulting from the blockchain transaction, based on a request to sell a previously acquired crypto asset, and the cost basis of the crypto asset can be recorded in the user specific database 140.
  • the back-end module 120 can subtract the cost basis to the value of the crypto asset sold during the blockchain transaction to calculate the profit or loss associated thereto.
  • some calculations can only impact the15escry15e of the blockchain transaction associated with the crypto asset. For instance, if a blockchain transaction relates to a deposit into a lend and borrow blockchain protocol, the technique can subtract the balance of the crypto asset in the user-provided blockchain address but will add the same balance for a user-specific account on the blockchain protocol.
  • An appropriate accounting technique can be selected based on the previously predicted information (i.e. , blockchain network, blockchain protocol and transaction type).
  • the back-end module can select an accounting technique adapted to calculate the financial position based on the type of crypto asset that is involved in the blockchain transaction.
  • calculating the financial position associated with the blockchain transaction can include determining suggested value of the transaction corresponding to a change in financial parameters resulting from the transaction. For example, in some embodiments, this can include calculating a net change in holdings, such as a net increase or a decrease in one or more crypto assets. In some configurations, calculating the financial position can further include calculating fees associated with the blockchain transaction. For example, a transaction on the Ethereum blockchain network can incur variable fees, and the financial position calculation can therefore account for such fees deducted for the transaction.
  • the back-end module 120 can be configured to calculate a financial position for each of the crypto assets in the blockchain transaction (i.e., execute an accounting technique for each crypto asset).
  • the suggested value can be used by the front-end module 110 to update a trading position associated with the user-provided blockchain address.
  • the back-end module 120 can be configured to aggregate values of a plurality of transactions associated with the user-provided blockchain address, including the suggested value of the current transaction and transactions previously calculated, in order to establish the trading position associated with the user-provided blockchain address.
  • the trading position can be provided by the back-end module 120 to the front-end module 110 and be presented as part of a graphical user interface (GUI) including a dashboard which displays different aspects of the trading position, including net worth, cost basis, open profit and loss, closed profit and loss, debt, cash balance, fees, individual active positions, closed positions, claim/compound, NFTs, investments, etc.
  • GUI graphical user interface
  • the front-end module 110 can be configured to calculate and display the different aspects of the trading position in a specified fiat currency, for example using an external price feed that provides an association between crypto assets and the specified currency. The price feed can be refreshed at regular intervals.
  • blockchain transaction indexing steps 210 to 260 were described as being performed by the back-end module 120, it is appreciated that in other embodiments some or all of these steps (i.e., steps 210 to 260) can instead be performed by the front-end module 110. In some embodiments, the parts of steps 210 to 260 can be shared or divided between the front-end 110 and back-end 120 modules. In some embodiments, some of the steps can be performed by other modules of the computing platform 100.
  • the suggested value and the predicted parameters associated with the blockchain transaction can be presented by the front-end module 110 to the user for confirmation.
  • the GUI provided by the front-end module 110 can include a section that lists transactions associated with the user-provided blockchain address.
  • the blockchain transaction can be included in the list of transactions and flagged as a pending or unconfirmed transaction.
  • the transactions can be flagged as such for example if the predicted parameters are based on mappings from the global database 130 and not already overridden or confirmed by preferences in the user-specific database 140.
  • the transactions can also be flagged as such parameters could not be predicted for the transactions (e.g., if there are no corresponding mappings in the global database or userspecific database).
  • the front-end module 110 can solicit the user to confirm the predicted parameters associated with the transaction or edit and/or modify the predicted parameters.
  • front-end module 110 can include a GUI that presents the unconfirm transaction along with the predicted information associated with the unconfirmed transaction, and provides controls that allow a user to confirm the transaction or suggest edits or modifications to the predicted parameters associated with the blockchain transaction such as the predicted blockchain protocol and/or the predicted transaction type.
  • the GUI is presented to the user via the user device 20, allowing the user to provide input to confirm and/or propose modifications to the predicted parameters associated with the blockchain transaction via the user device 20.
  • the predictions presented to the user can be provided via a web page, accessible by a browser on the user device 20, or via a native application running on the user device 20.
  • the front-end module 110 can receive an input from the user, either confirming that the predicted parameters associated with the blockchain transaction are correct, or that modifications should be made to one or more of the predicted parameters.
  • the input can correspond to a proposed modification to at least one of the predicted blockchain protocol and the predicted transaction type.
  • An input proposing a modification to the predicted blockchain protocol can include suggesting another known blockchain protocol that should be associated with the blockchain transactions and/or adding a new blockchain protocol that has not yet been mapped by the back-end module 120.
  • further parameters associated with the blockchain transaction can be modified, such as adding and/or changing quantities of incoming and/or outgoing crypto assets involved in the transaction and/or adjusting fees associated with the transaction.
  • Steps 280 and 290 are performed by the front-end module 110 depending on whether the received input corresponds to a confirmation of the predicted parameters (i.e., the users does not propose changes to the predicted parameters), or the receive input includes proposed modifications (i.e., edits) to the predicted parameters.
  • the input includes proposed changes to the blockchain protocol and/or transaction type, or does not include any changes, the input provided by the user can be used to adjust and increase the accuracy of future predictions made by back-end module 120.
  • Step 280 can be carried out when the input received from the user corresponds to a confirmation that the predicted transaction parameters are correct (i.e., the does not propose any changes to the predicted parameters).
  • the front-end module 110 can be configured to update the status of the transaction in the GUI, such that the status of the transaction is changed from pending to confirmed. Future calculations to update the trading position associated with the user-provided blockchain address can take for granted that the transaction parameters used to calculate the value associated with the transaction are correct.
  • the font-end module 110 upon receiving an input confirming that the predicted transaction parameters are correct, can communicate such confirmation to the back-end module 120.
  • the back-end module 120 can subsequently update the mappings of the predicted parameters in the global database 130 to reinforce the confidence of such mappings, thereby strengthening predictions for future transactions.
  • Step 290 can be carried out when the input includes at least one proposed modification by the user to at least one parameter associated with the blockchain transaction.
  • the modified parameters as confirmed by the user are received at the front-end module 110 and are then transmitted to the back-end module 120 for storage in the user-specific database 140.
  • the changes made by the user i.e., confirmed blockchain protocol and confirmed transaction type
  • the changes made by the user are kept as personal “preferences” that override the predictions made by the back-end module 130 for the transaction.
  • preferences stored in the user-specific database 140 can also be applied to future blockchain transactions that have the same characteristics as the confirmed transaction.
  • transaction preferences made by a user and stored in the user-specific database 140 are local to the user and are not shared with other users. It should also be appreciated that, in some configurations, a user can do a “hard reset” of their user-specific database 140 to remove preferences applied to some or all of their transactions and revert to default predictions provided by the back-end module 120. For example, in a case where the user is not satisfied with a modification or has made a mistake, the user can transmit, via the user device 20, a request to remove the modification. In some embodiments, the front-end module 110 can transmit a request to the back-end module 120 to delete all modifications stored in the user-specific database 140.
  • the back-end module 120 can carry out a verification process 300 to better understand the nature of the proposed modification and determine action that should be taken in response to the proposed modification.
  • the verification process can include verifying the smart contract address in the blockchain transaction type filter, and determining whether the proposed transaction type already exists for that smart contract and/or if a new transaction type should be added for that smart contract.
  • the verification process can include verifying whether the confirmed blockchain protocol already exists in the protocol filter, or if it corresponds to a new protocol that would need to be added (i.e., to avoid duplicates in the protocol filter).
  • the verification process can involve determining whether or not the proposed modification is authorized.
  • the global database 130 can include a list of whitelisted protocols or tokens, and the back-end module 120 can refuse the proposed modification if the proposed modification includes changing the transaction type to “Spam” for a protocol or token that is determined to be part of the whitelist.
  • the verification process is not limited to the above-provided examples and can include other forms of verification.
  • the proposed modification to the at least one transaction parameter can be stored by the back-end module 120 in the user-specific database 140 as a preference, and the blockchain transaction can be treated as a confirmed transaction for subsequent calculations.
  • the front-end module 110 can be configured to update the status of the transaction in the GUI, such that the status of the transaction is changed from pending to confirmed. Future calculations to update the trading position associated with the user-provided blockchain address can utilize the modified transaction parameters as confirmed by the user.
  • the modification of a transaction parameter associated with a blockchain transaction can trigger a re-calculation of the trading position associated with the user-provided blockchain address.
  • the back-end module 120 can repeat steps 220 to 250 to re-calculate the financial position associated with the blockchain transaction and any other transactions linked thereto using the modified transaction parameters.
  • the back-end module 120 can subsequently aggregate values of the plurality of transactions associated with the user-provided blockchain address, including the re-calculated transactions, to establish an updated trading position associated with the user-provided blockchain address.
  • the updated trading position can subsequently be presented by the front-end module 110 in the dashboard of the GUI on the user device 20.
  • received user inputs proposing modifications to predicted transaction parameters can be used to automatically update the global database 130 in order to improve future predictions for all users.
  • different validation mechanisms can be applied by the back-end module 120 prior to updating the global database 130 automatically.
  • a validation mechanism can include applying a threshold prior to updating the transaction type filter in the global database 130.
  • the back-end module 120 can be configured to update the global database 130 to add or change a mapping between transaction characteristics and a Transaction type only if it determined a threshold number of users, such as at least 20 users, have proposed applying the same transaction type to transactions having the same transaction characteristics.
  • the back-end module can be configured to update the mapping in the global database 130 if a threshold percentage of users proposed applying the same transaction type, such as more than 50% of users that have proposed modifications to transactions having the same transaction characteristics.
  • different thresholds can be used as needed.
  • thresholding can also be applied prior to making global changes to other transaction parameters.
  • another validation mechanism includes identifying duplicates prior to updating the protocol filter in the global database 130. More specifically, upon receiving an input that proposes adding a new transaction protocol, the back-end module 120 can be configured to determine whether a duplicate entry for the transaction protocol already exists in the protocol filter, and automatically adding the transaction protocol to the protocol filter in the global database 130 only if a duplicate does not exist. For example, a user proposes adding a new transaction protocol associated with a blockchain address, it can be determined whether that blockchain address is already mapped in the protocol filter. If a mapping already exists, the modification can be flagged for manual review by an administrator instead of being automatically added to the protocol filter in the global database 130.
  • a further validation mechanism includes manual validation by an administrator of the system to determine the legitimacy of some proposed modifications.
  • the global database 130 can be updated, and new information can be pushed to all users, only if a proposed modification is validated beforehand.
  • proposed edits to an existing protocol associated with a transaction and/or proposed additions of crypto assets involved in a transaction can be subject to manual review by an administrator before modifying the global database 130 accordingly.
  • manual validation can be applied to proposed modifications to other transaction parameters as well.
  • a second exemplary verification process 300b is illustrated in 300b.
  • the validation mechanism includes comparing input of several users and updating the global database 130 if a consensus or confidence is reached. More specifically, the back-end module can be configured to compare whether a minimum number of reliable users have provided input proposing similar modifications in transaction characteristics and/or transaction types and update the global database 130 if the minimum number of reliable users is reached.
  • the determination that a consensus or minimum confidence is reached is based on a reputation system.
  • reputation system it is meant that a score is assigned to each user of the platform, with the score corresponding to the user’s trust or reputation on the platform. A user’s score can change over time, with points being awarded or subtracted from the user depending on the nature of their proposed edits.
  • a high score can indicate that the user has a good reputation on the platform (e.g., has proposed many correct edits in the past), whereas a low or negative score can indicate that the user has a low or bad reputation on the platform (e.g., has made few correct edits in the past, and/or has made many incorrect edits in the past).
  • the score can be used as a weight or a measure of the probability of change proposed by a user being correct.
  • an aggregate score of users providing similar edits is used to decide whether the edit should be accepted and the global database 130 should be updated, or if the edit should be rejected. More specifically, a minimum point threshold can be defined, and a proposed edit can be accepted only if an aggregate score of users proposing the same or similar edit teaches the minimum points threshold.
  • the back-end module 120 can first compare the user input with entries in the global database to determine a corresponding proposed change to a mapping in the back-end database. Once a proposed change to the global database is determined, the back-end module 120 can verify whether the same change was proposed by other users via edits to similar transactions. In verifying whether the same change was proposed, the back-end module can determine whether a minimum points threshold is reached or not. If the threshold is not reached, the proposed change can be kept in standby without any change being applied to the global database.
  • putting on standby can include that the back-end module 120 can be configured to wait until another user proposes a similar change before performing the verification again.
  • putting on standby can include that the proposals submitted for modification can be reviewed by at least one administrator of the platform. If the threshold is reached, the global database can be updated to incorporate the proposed change. Once the proposed change is incorporated, the reputation score of users participating in that change can be updated. For example, it can be determined that a user edit is correct if the user proposed an edit to a transaction that is in line with the change made to the global database (i.e., an edit that agrees with the consensus). A user that proposed a correct edit can have points granted to increase their score.
  • a user edit is incorrect if the user proposed an edit to a transaction that goes against the change made to the global database (i.e., an edit that is contrary to the consensus).
  • a user that proposed an incorrect edit can have points removed to decrease their score. Changes made to the global database in this fashion can be used to update parameter predictions for future transactions. In some embodiments, the changes can also allow proposing changing predicted parameters for past transactions.
  • determining whether the minimum points threshold has been met can comprise aggregating or calculating a sum of points of all users proposing a change to the global database.
  • the back-end module 120 can determine that a plurality of users have proposed a change to a same entry in the global database by making edits or modifications to similar transactions.
  • the plurality of users can be grouped, and a total score (Y) can be calculated based on the sum of the points of these users (e.g., user 1 , user 2, and user 3).
  • the back-end module 120 can then determine if the total score (Y) is greater than a predetermined minimum points threshold.
  • the back-end module can further determine whether a minimum number of users (such as a minimum of three users) have proposed the same change. If the total score is greater then the threshold and the minimum number of users is reached, the global database can be updated with the proposed change. The reputation score of users can then be updated. If the total score (Y) is less than the predetermined threshold and the minimum number of users is not reached, the proposed change can be put on standby while awaiting input from sufficient users. In some embodiments, if the total score (Y) is less than the predetermined threshold and the minimum number of users is reached, the change can be rejected, and the reputation score of users participating in the incorrect edit can be updated accordingly.
  • a minimum number of users such as a minimum of three users
  • GUI 400 can be provided on a web page of a front-end server or on a native application of the user devices. Accordingly, the user can have access to the graphical user interface 400 as displayed via a smartphone, computer, smartwatch or any available device adapted to display such a graphical user interface. Also, the results of steps performed by the method can be displayed via the graphical user interface 400. In particular, a user can be presented with different aspects of the trading position associated with the user-provided blockchain address, including a list of blockchain transactions associated with the address, and controls to confirm and/or modify the provided predicted parameters associated with the transactions.
  • Figures 4 is a screenshot presented on the user device of the main section of the interface 401 (i.e., the dashboard).
  • the main section 401 can be presented after the user has entered their blockchain address or human-readable name associated with their blockchain address.
  • the user can have access to general information about the status of their portfolio.
  • the graphical user interface 400 can display the currently opened transactions (Open P&L) and currently closed transactions (Closed’s P&L), as well as the status of the positions for different blockchains and blockchain protocols, in which the user currently has holdings.
  • Figure 5 is a screenshot of the transaction section 402 of the graphical user interface, listing the transactions associated with the user-provided blockchain address).
  • the user can view, for each blockchain transaction, the transaction parameters predicted by the computing platform 100, and corresponding values and/or trading positions calculated therefrom.
  • Figure 6 is a screenshot of a modal window 403 allowing the user to consult the predicted information for a transaction.
  • the modal window 403 can be displayed following selection of an individual transaction in the list of Figure 4.
  • controls are provided allowing the user to confirm the predicted information of the transaction (with the validate button) or apply modifications.
  • Figure 7 is a screenshot of another submenu 404 allowing the user to modify the type of transaction. As shown, transaction types most commonly used (or type of transactions occurring the most frequently) are displayed at the top of the submenu. Other types of transactions can be selected by scrolling down the drop-down menu.
  • Figure 8 is a screenshot of another submenu 405 allowing the user to select a crypto asset associated with the blockchain transaction (such as a token or an NFT). As shown, the most commonly known tokens (or the tokens traded most frequently) are displayed at the top of the submenu and other types of tokens can be selected by scrolling down the drop-down menu.
  • Figure 9 is a screenshot of another submenu 406 allowing the user to select a protocol associated with the blockchain transaction. As shown, the most commonly known blockchain protocols (or the blockchain protocols most commonly used) are displayed at the top of the submenu and other types of protocols can be selected by scrolling down the drop-down menu.
  • Figure 10 is a screenshot of another modal window 407 allowing the user to consult the predicted information for a transaction. This screenshot shows controls that allow the user to change incoming and outgoing crypto assets associated with a transaction, as well as the transaction information associated with each asset.
  • graphical user interface 400 is not limited to the menus and submenus disclosed above and can provide/display other features and functionalities to the user.
  • indexing blockchain transaction were performed for a single user-provided blockchain address
  • other configurations can include the indexation of blockchain transactions associated with a plurality of blockchain addresses.
  • a user can have a portfolio that comprises trades and holdings spread across a plurality of different blockchain addresses.
  • the user can provide, via user device, the plurality of blockchain addresses (i.e., multiple wallet addresses) in order to be presented an overall trading position comprising an aggregation of the trading positions associated with their plurality of blockchain addresses.
  • the front-end module can send a request to the back-end module to calculate trading positions associated with a plurality of different blockchain addresses.
  • the back-end module can query the required blockchains and index the transactions as described above to establish the trading position associated with the blockchain address.
  • the trading positions associated with each of the plurality of blockchain transactions can then be sent to the front-end module which can subsequently aggregate the trading positions to establish an overall trading position.
  • the front-end module can aggregate the blockchain transactions and financial positions associated with each of the plurality of blockchain address in order to display the overall trading position to the user via the user device (ex: display an overall trading position of trades and assets in a plurality of wallets and/or trading accounts held by the user).
  • aggregating the trading positions in this fashion can allow the overall trading position of a given user (i.e. , the overall picture of a user’s full crypto “portfolio”) to be only available via the front-end module and user device, whereas the back-end module can only be aware of trading positions of individual blockchain addresses.
  • the described system is capable of receiving and indexing blockchain transactions from a plurality of blockchain networks.
  • the system can be provided with a back-end module, a front-end module, a global database and a user-specific database configured to present predictions about the blockchain transactions to a user’s device.
  • a method of indexing blockchain transactions associated with a blockchain address has also been described. An advantage of this method is that it allows the user to modify the predictions transmitted to him in relation to the transactions and to learn from these modifications in order to provide more accurate estimations for future transactions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé d'indexation de transactions de chaîne de blocs. Le procédé comprend généralement : la demande de transactions associées à une adresse de chaîne de blocs ; la réception des transactions d'un réseau de chaîne de blocs ; et pour chacune des transactions : la prédiction d'un protocole de chaîne de blocs associé à la transaction sur la base d'une adresse source ou d'une adresse de destination de la transaction ; la prédiction d'un type de transaction associé à la transaction sur la base d'au moins une caractéristique de la transaction ; et le calcul d'une position financière de la transaction sur la base du protocole de chaîne de blocs et du type de transaction. L'invention concerne en outre un système et un support lisible par ordinateur correspondants.
PCT/CA2023/051201 2022-09-12 2023-09-11 Système et procédé d'indexation de transactions de chaîne de blocs WO2024055103A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263375324P 2022-09-12 2022-09-12
US63/375,324 2022-09-12

Publications (1)

Publication Number Publication Date
WO2024055103A1 true WO2024055103A1 (fr) 2024-03-21

Family

ID=90274000

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2023/051201 WO2024055103A1 (fr) 2022-09-12 2023-09-11 Système et procédé d'indexation de transactions de chaîne de blocs

Country Status (1)

Country Link
WO (1) WO2024055103A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170132625A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for use of a blockchain in a transaction processing network
US20170132626A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for processing of a blockchain transaction in a transaction processing network
US20190238316A1 (en) * 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment
US20200250174A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (dlt)
US20200374105A1 (en) * 2019-05-22 2020-11-26 Salesforce.Com, Inc. System or method to implement consensus on read on distributed ledger/blockchain

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170132625A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for use of a blockchain in a transaction processing network
US20170132626A1 (en) * 2015-11-05 2017-05-11 Mastercard International Incorporated Method and system for processing of a blockchain transaction in a transaction processing network
US20190238316A1 (en) * 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment
US20200250174A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (dlt)
US20200374105A1 (en) * 2019-05-22 2020-11-26 Salesforce.Com, Inc. System or method to implement consensus on read on distributed ledger/blockchain

Similar Documents

Publication Publication Date Title
US11601550B1 (en) Methods and systems for customizing interactive voice response calls
US11900271B2 (en) Self learning data loading optimization for a rule engine
US7805348B2 (en) Systems and methods enabling investment activities via the creation and use of client-specific security files
US11978056B2 (en) Systems and methods for using shared databases for managing supplemental payment sources
KR20210050525A (ko) 분할 가능한 증권형 토큰
US11893627B2 (en) Adaptive risk-based verification and authentication platform
US20100191672A1 (en) Systems, methods, and computer program products for adjusting the assets of an investment account
US20210326886A1 (en) Blockchain-based resource transaction methods, apparatuses, and systems
CN114641787A (zh) 优化通过计算机网络的交易的路由的系统和方法
KR102410777B1 (ko) 상품 추천 방식 개선 방법 및 장치
CN109285069B (zh) 资源转移方法、装置及服务器
US11532054B2 (en) Path of funds blockchain system
US20240062182A1 (en) User interfaces for using shared databases for managing supplemental payment sources
JP6409115B1 (ja) 自動仕訳サーバおよび自動仕訳プログラム
US20230298016A1 (en) Systems and methods for validating asset destinations in blockchain networks
CN110245954B (zh) 用于风险控制的方法和装置
US20230004973A1 (en) Authenticating Based on Behavioral Transactional Patterns
US20200104912A1 (en) Systems and methods for real-time allocation of resources
WO2024055103A1 (fr) Système et procédé d'indexation de transactions de chaîne de blocs
US20230091063A1 (en) Systems and methods for real-time processing of resource requests
US20220215468A1 (en) Computer Implemented Lending Management System and Method
US20140236781A1 (en) Systems and Methods for an In-Memory Budget Finder
US11756112B2 (en) Settings optimization engine using artificial intelligence to enhance client privacy
US11803915B1 (en) Computing system for adaptive investment recommendations
US10679293B2 (en) System and method for risk matching clients with insurance companies

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23864200

Country of ref document: EP

Kind code of ref document: A1