A method for propagating survival of cryptographic currency after inactivity over a predetermined period of time in a blockchain through the use of smart contracts includes: receiving a propagation request that includes unspent transaction output addresses, a digital signature, and a recipient address; generating a smart contract that is configured to self-execute after a predetermined period of time to initiate transfer of cryptographic currency from the output addresses to the recipient address; submitting the smart contract to a node in a blockchain network for addition to the blockchain; monitoring for new blockchain transactions involving any of the unspent transaction output addresses; generating a new smart contract to update the unspent transaction output addresses based on new blockchain transactions; and submitting the new smart contract to a node in a blockchain network after updating.

A method and system for securing a peer-to-peer transaction between first and second computing devices includes: generating, using a blockchain network, digital tokens in an equivalent amount to fiat currency for making the peer-to-peer transaction; storing the digital tokens in a first digital wallet installed on the first computing device; receiving a request associated with the peer-to-peer transaction from the first computing device concerning a transfer of one or more of the digital tokens from the first digital wallet to a second digital wallet installed on the second computing device; validating the request by the blockchain network and, upon successful validation, storing data related to the peer-to-peer transaction on a distributed public ledger in a form of a blockchain; and transmitting a response to the first computing device instructing transfer of the one or more of the digital tokens to the second digital wallet of the second computing device.

There is provided a processor(s) executing a blockchain smart contract, for: managing a primary reserve of primary tokens and a secondary reserve of secondary tokens, receiving a transaction request, obtaining an external price of the primary token, compute an updated value of the primary reserve according to the external price, in response to the updated total value of primary reserve being unequal to an initial staked value of the primary reserve, adjust primary and secondary dynamic reserve weights, wherein a total value computed by a function of the primary reserve after being increased or decreased by a target amount of primary tokens and using the adjusted primary and secondary dynamic reserve weights, is equal to the initial staked value of the primary reserve, and the total value of the primary reserve is maintained at a predefined ratio to a total value of the secondary reserve, and executing the transaction request.

Aspects of the present disclosure involve a system and a method for performing operations comprising: receiving, by a messaging application, content from a given user; selecting a metric for measuring performance of the content on the messaging application; measuring performance of the content on the messaging application; computing a value of the performance of the content on the messaging application based on the selected metric; and updating a restricted use token wallet stored in a profile for the given user based on the computed value of the performance of the content.

A unified wallet manager (UWM) virtualized as a single virtual service in which all transactions relative to the UWM are treated as immutable facts permanently stored in append-only queues or ledgers from the time of their creation. A rules engine reads conversion requests in request calls to the service and determines which rule or rules, including responsible gaming rules, to apply to control or convert funds from one ledger to another, in the same or different vertically scaled gaming systems. The UWM is a peer of other vertical gaming systems, and the gaming systems access the UWM via an API server and data egresses from the UWM through an ETL process from a database cluster. The ledger stores funds of many different types, including real money, points, play money, and others. Third parties can integrate with the UWM through an integration hub connected to the UWM.

Method prevents duplicate data to be stored in storage having hosts which do not trust each other. The method includes storage including encrypted data blocks, network further including distributed ledger, accessible to each of two or more hosts. The method includes steps, performed by first host when the first host wishes to store a new data block, obtaining first hash value for new data block, determining if first hash value is found in ledger. If first hash value is not found in ledger, creating set of confirmation data, encrypting new data block with block-unique encryption key, and storing first ownership record in ledger. If first hash value is found in ledger, obtaining information about second host that has already stored previous block identical to new data block, entering in ledger key request, receiving from ledger key transfer record, sending to ledger new ownership record.

Methods and systems are disclosed for transactions with a private digital currency. The private e-currency may be backed by a financial institution, managed using a blockchain, and only available for transactions with members of a network associated with the financial institution. The members may include mobile wallets, merchants and ATM's. A mobile wallet may register with the network and receive an amount of the private e-currency from the financial institution. The mobile wallet may establish a connection with a payment recipient such as another wallet, an ATM or a merchant, and receive a payee address. The mobile wallet may send a transaction request to the blockchain for payment to the payee address of a payment amount of the private e-currency, so that the payment recipient can, using a blockchain, confirm or deny the transaction request.

A unified wallet manager (UWM) virtualized as a single virtual service in which all transactions relative to the UWM are treated as immutable facts permanently stored in append-only queues or ledgers from the time of their creation. A rules engine reads conversion requests in request calls to the service, and determines which rule or rules to apply to convert funds from one ledger to another, in the same or different vertically scaled gaming systems. The UWM is a peer of other vertical gaming systems, and the gaming systems access the UWM via an API server and data egresses from the UWM through an ETL process from a database cluster. The immutable queues allow for data reconstruction using any desired data model. The ledger stores funds of many different types, including real money, points, play money, and others. Third parties can integrate with the UWM through an integration hub connected to the UWM.

An asset transfer request to transfer an asset to a blockchain member associated with a blockchain is detected, where the asset is of a specified asset type and is issued by a specified anchor in the blockchain. Whether there is a maximum trusted asset limit configured by the blockchain member for the specified anchor and that corresponds to the specified asset type is determined. If it is determined that the maximum trusted asset limit is not configured, application of the asset transfer request to the asset is prohibited. However, if it is determined that the maximum trusted asset limit is configured, whether the maximum trusted asset limit is exceeded is determined. If it is determined that the maximum trusted asset limit is not exceeded, the asset transfer request is applied to the asset.

A computer-implemented method includes receiving, by a node in a blockchain network from a client node, a service initiation transaction broadcasted to the blockchain network, wherein each node of blockchain network comprises a blockchain virtual machine, an instruction set of the blockchain virtual machine comprises an XML processing instruction, and XML processing logic corresponding to the XML processing instruction is deployed in the blockchain virtual machine, an instruction set of a smart contract compiler comprises the XML processing instruction, and a service smart contract compiled by the smart contract compiler comprises the XML processing instruction, and is deployed in the blockchain network; invoking, using the blockchain virtual machine, the service smart contract; and triggering, using the blockchain virtual machine, execution of the XML processing logic based on the XML processing instruction in the service smart contract to perform an XML processing operation on data to be processed.