Abstract

This document relates to a smart contract-based platform that enables a group of individual users to provide liquidity to fund expenses and receive revenue associated with transactions between the platform smart contract and other users or contracts. When a user sends liquidity to or withdraws liquidity from the platform smart contract, account data for the user is updated (or created). The account data indicates an amount of liquidity associated with the account at the most recent time the account data was updated.

On each instance that the smart contract expends or receives liquidity due to a transaction, a ledger entry is created or updated. Each ledger entry indicates the total liquidity associated with the smart contract and the amount by which the total liquidity changed due to the transaction.

When a user requests to view the current amount of liquidity associated with that user’s account or requests to add or withdraw liquidity, each ledger entry that was created between the most recent update to the account data for that account and the time the request is received is used to update the amount of liquidity for the account via a synchronization process. Use of a system of ledger entries to update account data at the time when a request is received eliminates the need to continuously track the amount of liquidity associated with each individual account, enabling the platform to be scalable at a low computational cost. Additionally, use of a system of ledger entries enables the amount of liquidity associated with each account to be determined without using separate modules to generate and assign liquidity shares that represent underlying assets, as is commonly used with liquidity pools.

On each instance that a transaction changes the state of the smart contract, the synchronization process may be opportunistically performed to update the amount of liquidity associated with at least one account using the ledger entries. Opportunistic updating of account data in this manner enables future retrieval of information to occur more quickly and with less computational cost, and enables a ledger entry to be deleted once no account remains that has not been updated using that ledger entry, conserving memory and computational resources.

Introduction

Cryptocurrency-based decentralized finance (DeFi) enables many of the roles that have traditionally been performed by banks and centralized financial institutions to be undertaken by other individuals and entities.

One common DeFi application is the exchange of digital assets using a feature known as a liquidity pool. Multiple users may provide assets to a liquidity pool, each user obtaining an ownership share of the assets in the pool. When a transaction to exchange assets occurs, an amount of a first asset is provided into the liquidity pool, and an amount of a second asset that is equal in value to the amount of the first asset is removed from the liquidity pool. Most liquidity pools are configured to retain a fee for each transaction that is performed. Liquidity pool fees are typically divided among the users that provided assets, proportional to the amount of assets that each user provided relative to the total amount of assets in the liquidity pool. By providing liquidity to a liquidity pool, users may perform the roles traditionally performed by a bank or currency exchange: expending liquidity to fund transactions (such as currency exchanges) and receiving revenue associated with those transactions.

Liquidity pools typically track the amount of liquidity owned by each user through use of a specialized module that creates virtual tokens representing ownership shares of the liquidity pool. Each liquidity pool token represents a certain amount of underlying assets within the liquidity pool, that amount based on the total amount of assets in the liquidity pool and the total number of liquidity pool tokens that exist. The specific assets represented by a liquidity pool token therefore change each time that liquidity is added to or removed from a liquidity pool, and each time that a transaction is performed using the assets in the liquidity pool. The known underlying value of a liquidity pool token enables the amount of assets associated with an individual user to be continuously tracked based on the number of liquidity pool tokens that user owns.

We propose an alternative platform for enabling decentralized funding of transactions, and sharing in the revenue from transactions: a system of user accounts and ledger entries. This platform eliminates the need for a separate virtual asset, such as a token representing ownership shares for a pool of assets, and eliminates the need for specialized software for creating, destroying, and tracking the value of these separate virtual assets. Instead, changes in user-provided liquidity are recorded using account data, and changes in platform liquidity due to transactions are recorded using ledger entries. Account data is synchronized with ledger entries on-demand, such as when a user requests to view or withdraw liquidity. Computational efficiency may be improved by opportunistically synchronizing account data with ledger entries on each occasion that a contract state is changed, deleting deprecated ledger entries, and selectively updating existing ledger entries rather than creating new ledger entries when account data has not changed. The platform may therefore retrieve and update data quickly, on an as-needed basis rather than continuously tracking values, using comparatively small amounts of computational resources.

One example use case for this platform includes functioning as a source of funding for cryptocurrency-based games of chance (as “the house”). When a game of chance is played and won, user-provided liquidity may be used to provide winnings to the winning player, and the users that provided liquidity to the platform may share in the expenditure proportionally based on the amount of assets provided by each user. When a game of chance is played and lost, this loss may be added to the liquidity for the platform as revenue and distributed proportionally among the users in a similar manner.

In addition to this example use, the platform described herein may be used in conjunction with any type of transaction for which it is desirable to distribute expenses or revenue among users that have provided liquidity for this purpose.

Overview

(Link to Github)

The revenue and expense-sharing platform described in this paper may function as one or multiple smart contracts on any network capable of supporting the contract(s). To use the platform, a user may send a selected quantity of assets from a wallet to a designated smart contract (the “platform smart contract”). Based on the wallet address or other identifiable information, account data for that user may be accessed if such data exists, then updated using any ledger entries that have not yet been used to update the account, and further updated based on the amount of assets sent to the smart contract. If account data does not exist, such as when a user provides assets to the platform smart contract for the first time, account data may be created at that time.

The account data for a particular account may include:

• a wallet address or other identifier that is usable to distinguish a particular account from other accounts

• a total amount of liquidity provided by the user

• an amount of liquidity currently associated with the account (after the platform has spent or received liquidity and the account data has been synchronized based on ledger entries for one or more transactions)

• a sequence number or other identifier that indicates the latest ledger entry with which the account data has been synchronized

A user may remove assets from the platform using a similar process: A request to withdraw assets is received, the account data for the wallet address of the user is accessed, and the amounts of liquidity indicated in the account data are updated using any ledger entries that have not yet been used to synchronize the account. In some cases, all liquidity associated with an account may be withdrawn using this process. In other cases, the request may indicate a specified quantity of liquidity, a determination may be made that sufficient liquidity (greater than or equal to the selected quantity) is indicated in the account data, and the selected quantity of assets is then sent from the platform smart contract to the requesting wallet address.

When a transaction associated with the platform occurs, this transaction may result in an expense (removal of liquidity from the smart contract) or revenue (addition of liquidity to the smart contract). When the transaction occurs, a ledger entry may be created, or an existing ledger entry may be updated, that indicates the state of the smart contract and the change in liquidity that occurred due to the transaction.

A ledger entry may include:

• a sequence number or other identifier that is usable to distinguish a particular ledger entry from other ledger entries (typically an integer, N+1, that is greater than the sequence number of the preceding ledger entry, N)

• a total amount of liquidity that has been provided to the platform smart contract

• a current amount of liquidity associated with the platform smart contract (after the platform has spent or received liquidity)

• a change in liquidity associated with the transaction or set of transactions represented by the ledger entry

• a reference counter that indicates the number of user accounts having liquidity associated with the platform smart contract at the time the ledger entry was created

A new ledger entry may be created if the total amount of liquidity that has been provided to the smart contract has changed. For example, if a user has added liquidity to or removed liquidity from the platform since the previous ledger entry was created, a flag or value for the platform may be updated to indicate that a change in account data occurred. In such a case, the total amount of liquidity that has been provided would differ from the amount indicated in the previous ledger entry, and a new ledger entry may be created that includes the information indicated above. However, if no change in account data has occurred, the total amount of liquidity that has been provided would not differ from the amount indicated in the previous ledger entry. Creation of a new ledger entry would not be necessary in that case, because the portion of the total liquidity associated with each user account has not changed. In such a case, the most recent ledger entry may be updated by combining the change in liquidity associated with the most recent transaction with the change in liquidity indicated in the most recent ledger entry. By creating a new ledger entry only when the total amount of liquidity has changed, the total number of ledger entries may be retained to the minimum amount necessary, which may conserve time and computational cost associated with future synchronization of account data with ledger entries.

When a user requests to withdraw liquidity from the platform, a synchronization process is performed in which the sequence number for that user’s account is compared to the sequence numbers for the ledger entries. Each ledger entry having a sequence number that is greater than the number associated with the user account represents a change in liquidity that has not yet been reflected in the account data for that account. Through the synchronization process, each ledger entry having a sequence number greater than the sequence number associated with the account is used to sequentially update the amount of liquidity for the account.

For each ledger entry having a sequence number greater than the sequence number associated with the account:

• the portion of the platform liquidity owned by the account is determined by dividing the current account liquidity indicated in the account data by the current platform liquidity indicated in the ledger entry

• the change in liquidity owned by the account is determined by multiplying the change in liquidity indicated in the ledger entry by the number determined above

• the current amount of liquidity associated with the account is updated in the account data

• the sequence number associated with the account data is incremented by one

• the reference counter associated with the ledger entry is decremented by one

• this process is repeated for each subsequent ledger entry until the sequence number for the account data is equal to the sequence number of the latest ledger entry

After the above process has been completed, the account data for the user’s account has been synchronized with each ledger entry and indicates the current amount of liquidity associated with the account, which may be withdrawn.

When a user requests to view the amount of liquidity associated with that user’s account, such as through use of a webpage or other type of interface, a similar process to the above may be performed. However, because the state of the smart contract is not accessed and changed as a result of this request, this process may be a read-only process. In such a case, the calculations above may be performed to determine an amount of liquidity to be displayed in an interface, but the account data and ledger entries would not be modified through the read-only process.

To reduce the time and computational resources used when a user requests to withdraw liquidity or view the amount of liquidity associated with that user’s account, the synchronization process described above may be opportunistically performed for one or more accounts when other processes are performed that change the state of the platform smart contract.

For example, a queue of accounts may be maintained, and on each instance that a transaction occurs, in addition to creating or updating a ledger entry or account data based on the transaction, the synchronization process described above may be performed for the first account in the queue. The account may then be moved to the end of the queue. By synchronizing at least one account on each instance that a transaction occurs, at a future time when a user requests to withdraw liquidity, add liquidity, or view the amount of liquidity associated with that user’s account, a smaller number of ledger entries that were created after the most recent synchronization of the account will exist. This enables the current amount of liquidity associated with an account to be determined more quickly and at a lower computational cost. Use of a queue of accounts, in which an account is moved to the end of the queue after being synchronized, increases the likelihood that an account synchronized in this manner will be an account that has not recently been synchronized.

As noted above, when a ledger entry is created, the ledger entry includes a reference counter that indicates the number of accounts that have liquidity associated with the platform at the time of creation of the ledger entry. Each time that the ledger entry is used to synchronize an account, the reference counter is decreased by one. When the reference counter reaches zero, this indicates that no account data remains that has not been updated based on that ledger entry. Therefore, once a reference counter for a ledger entry reaches zero, retaining that ledger entry is no longer necessary and the ledger entry may be deleted, conserving memory and computational resources.

The platform described in this paper therefore enables a user to provide liquidity to a platform, receive a share of revenue or expenses associated with various transactions, and view or withdraw a current amount of liquidity associated with that user’s account, without requiring use of specialized modules that create virtual tokens representing underlying assets or continuously tracking the amount of assets associated with each account. Instead, a sequence of ledger entries that indicate changes in liquidity for the platform is maintained, which uses a comparatively small amount of memory and computational resources by enabling current amounts of liquidity for accounts to be determined on an as-needed basis, enabling the system to be scalable. Creating new ledger entries only at times when liquidity associated with one more accounts has changed (while updating the most recent ledger entry at times when account data has not changed), opportunistically synchronizing at least one account with the ledger entries each time the platform smart contract changes state, and tracking and removing ledger entries that are no longer needed for future synchronization processes enables the platform to operate quickly, in a scalable and computationally efficient manner.

Account Creation and Addition of Liquidity

A user account may be created, or the amount of liquidity associated with an account may be increased, when a wallet address is used to send assets to the platform smart contract. The wallet address may be used as a unique identifier to differentiate an account from other accounts, though it is also possible to use a different identifier in addition to or in place of the wallet address.

When an amount of liquidity is received from a wallet address, a determination may be made whether account data currently exists for that wallet address (or a corresponding identifier). If account data exists, that account data may be retrieved. Otherwise, new account data may be created.

Account data for each account includes:

• A wallet address or other unique identifier associated with the account

• A total amount of liquidity that has been provided by the wallet address

  • If the account data is newly-created, this amount will be equal to the amount of liquidity currently sent by the wallet address

  • If the account data is preexisting, this amount will be equal to the sum of the previous total liquidity and the amount currently sent

• A current amount of liquidity associated with the wallet address

  • If the account data is newly-created, this amount will not yet exist

  • If the account data is preexisting, this amount may differ from the total amount of liquidity due to one or more transactions associated with the platform that resulted in adding or removing liquidity associated with the account

• A sequence number representing the latest ledger entry used to synchronize the account data

  • If the account data is newly-created, this number will initially be set as equal to the sequence number of the most recent ledger entry

  • If the account data is preexisting, this number may be less than or equal to the sequence number for the latest ledger entry

Before the current amount of liquidity associated with the account data is updated based on the liquidity received from the wallet address, a synchronization process is performed to update the preexisting current amount of liquidity based on any ledger entries that have not yet been used to synchronize the account data.

If the sequence number for the account data is currently equal to that of the latest ledger entry, which may occur for a newly-created account or an existing account that has been previously synchronized using the most recent ledger entry, the amount of liquidity received from the wallet address may be added to the existing current amount of liquidity to determine an updated current amount of liquidity for that account.

If the sequence number for the account data is not equal to that of the latest ledger entry, the account data is synchronized using each ledger entry that has not yet been used to synchronize the account data to determine the current amount of liquidity associated with the account data. Then, the amount of liquidity received from the wallet address may be added to the synchronized current amount of liquidity to determine an updated current amount of liquidity for that account.

After the account data for a user account is created or updated, a flag or value for the platform smart contract may be updated to indicate that a change in liquidity associated with a user account occurred. This flag or value may cause the smart contract to generate a new ledger entry on the next instance that a transaction occurs, rather than updating the most recent ledger entry.

Optionally, because the addition of liquidity to the platform smart contract is a transaction that resulted in a change in state of the platform smart contract, account data for one or more additional accounts may also be opportunistically synchronized. For example, a queue may be maintained and the account data indicated at the top of the queue may be synchronized using any ledger entries that have not yet been used to synchronize the account data. That account data may then be placed at the end of the queue. The account data associated with the wallet address that provided additional liquidity may also be placed at the end of the queue since the account data was synchronized as part of the process to add liquidity.

Transactions that Affect Platform Smart Contract Liquidity

The liquidity that has been provided to the platform smart contract by one or more users may increase or decrease as a result of various transactions associated with the platform. For example, the total liquidity associated with the smart contract may decrease if expended to pay an expense associated with a transaction. The total liquidity may increase if revenue is received as a result of the transaction.

As described previously, an example use case may include use of liquidity associated with the platform smart contract as a source of funding for cryptocurrency-based games of chance. When a game of chance is won by a player, total liquidity associated with the smart contract may decrease as liquidity is expended to provide an amount of assets that have been won to the wallet address of the winning player. When a game of chance is lost by a player, total liquidity associated with the smart contract may increase as assets spent by the player to participate in the game of chance are added to the liquidity associated with the smart contract. Changes in liquidity that occur as a result of such transactions are allocated to the users that provided liquidity to the smart contract, proportional to the amount of liquidity associated with each user’s account.

While funding for cryptocurrency-based games of chance is presented as one example use, any transaction that may result in revenue or an expense may be supported using the system described in this document.

When a transaction occurs that results in a change in total liquidity for the platform smart contract, a determination is made whether liquidity associated with an account has changed since the most recent ledger entry was created. As described previously, if liquidity has been added to or removed from an account, resulting in a change in account data for that account, a flag or other type of value may be toggled or incremented to reflect this change.

If liquidity has been added to or withdrawn from one or more accounts since the most recent ledger entry was created, a new ledger entry may be created, and the flag or value used to indicate the change in account data may be toggled or incremented to remove the indication of a change in account data. If account liquidity has not changed since the most recent ledger entry was created, the most recent ledger entry may instead be updated based on the change in liquidity associated with the transaction.

A ledger entry may include:

• A sequence number or other unique identifier

  • Sequence numbers for ledger entries may be a set of integers, with each ledger entry being assigned a sequence number that is one greater than the sequence number for the preceding ledger entry

• A total amount of liquidity that has been provided to the platform smart contract

• A current amount of liquidity associated with the platform smart contract (after increases or decreases in liquidity associated with previous transactions)

• A change in liquidity associated with the current transaction (or a set of transactions if an existing ledger entry has been updated due to one or more subsequent transactions that occurred after its creation)

• A reference counter

  • When a ledger entry is created, a reference number is assigned that is equal to the number of accounts that have added liquidity to the platform smart contract

  • On each instance that the ledger entry is used to synchronize an account, this number is decremented

  • When this number reaches zero, it is possible to delete the ledger entry since all accounts have been synchronized based on the information in the ledger entry

If a new ledger entry is created:

• The ledger entry may be assigned a unique sequence number (typically an integer that is one greater than the sequence number of the previous ledger entry)

• The total liquidity indicated in the new ledger entry may be determined based on the total liquidity associated with each account including any change(s) in account data that have occurred after creation of the previous ledger entry

• The current liquidity indicated in the new ledger entry may be determined based on the current liquidity indicated in the previous ledger entry, the change in liquidity associated with the transaction indicated in the previous ledger entry, and the change(s) in account data that occurred after creation of the previous ledger entry

• The change in liquidity associated with the current transaction may be determined based on the transaction in response to which the ledger entry was created

• The ledger entry may be assigned a reference value equal to the number of accounts that have provided liquidity to the platform smart contract at the time the ledger entry is created

If an existing ledger entry is updated:

• The sequence number, total liquidity, current liquidity, and reference value may remain unchanged

• The change in liquidity associated with the transaction may be updated by summing the existing change in liquidity with the change associated with the current transaction

  • The resulting change in liquidity may therefore be indicative of changes associated with multiple transactions

Optionally, because a transaction occurred that resulted in a change in state of the platform smart contract, account data for one or more accounts may also be synchronized after creating or updating a ledger entry. As described previously, a queue may be maintained and the account data indicated at the top of the queue may be synchronized using any ledger entries that have not yet been used to synchronize the account data. That account data may then be placed at the end of the queue.

Synchronization

The synchronization process described in this paper enables liquidity amounts for specific accounts to be determined as-needed, without continuously tracking the amount of liquidity associated with an account, as an alternative to use of separate modules to generate and assign liquidity share tokens that represent underlying assets. This synchronization process is performed on each occasion that the platform smart contract changes state, such as when the liquidity associated with the smart contract changes as a result of a transaction.

Opportunistically performing this process at times when another transaction occurs enables the benefits of the synchronization process to be obtained without incurring the computational cost associated with separately initiating the synchronization process. Additionally, performing this process on each instance that a transaction occurs may result in frequent synchronization of accounts, which may enable subsequent requests to withdraw or view liquidity associated with an account to be performed more quickly and at a smaller computational cost, and may enable ledger entries to be deprecated and deleted more quickly.

When a transaction that changes the state of the smart contract occurs, the liquidity associated with the contract may change. For example, when a transaction results in the contract expending liquidity to pay an expense for an associated project or receiving liquidity as revenue from the associated project, the synchronization process may be performed for at least one account after completion of this transaction. As described previously, one example of such a transaction may include completion of a game of chance, after which the smart contract may spend liquidity to provide winnings to the player if the game was won, or receive liquidity from the assets spent to participate in the game if the game was lost. Other transactions that may change the state of the contract include the addition or withdrawal of liquidity by a user.

After a transaction has been performed, a ledger entry may be created or updated indicating the total and current liquidity for the smart contract and a change in liquidity associated with the transaction. After the addition or removal of liquidity by a user, account data for the associated user account may be created or updated. The synchronization process may be initiated after either of these processes have been completed.

An account may be selected for synchronization through use of a queue. For example, a queue of accounts may be maintained, and on each instance that the synchronization process is performed, the account indicated at the top of the queme may be synchronized. The synchronized account may then be placed at the bottom of the queue. It is also possible to use other methods for selection of an account for synchronization, such as selecting an account randomly, or selecting based on other characteristics such as account age, amount of liquidity associated with an account, or recent activity associated with the account.

As described previously, each ledger entry includes a unique sequence number, and account data for each account includes a sequence number indicating the most recent ledger entry that was used to synchronize the account.

In cases where the sequence number indicated in the account data is equal to the sequence number of the most recent ledger entry, this indicates that the account is currently synchronized with the most recent transaction(s) and the current amount of liquidity indicated in the account data is accurate.

If the sequence number indicated in the account data is not equal to the sequence number of the most recent ledger entry, this indicates that the account is not currently synchronized with the most recent transaction(s).

In such a case, the account data may be synchronized by:

• Accessing the ledger entry having a sequence number immediately following the sequence number associated with the account data

• Determining the portion of the platform smart contract liquidity attributable to the account

  • This may be determined by dividing the current amount of liquidity for the account indicated in the account data by the current amount of liquidity for the platform indicated in the subsequent ledger entry

• Determining the portion of the change in liquidity for the ledger entry that is attributable to the account

  • This may be determined by multiplying the change in liquidity indicated in the ledger entry by the portion of the smart contract liquidity determined above

• Updating the current amount of liquidity associated with the account data

  • This may be determined by summing the current amount of liquidity indicated in the account data with the portion of the change in liquidity determined above

• Incrementing the sequence number for the account data to reflect that the account data has been synchronized with the subsequent ledger entry

• Decrementing the reference value for the ledger entry to reflect that an account has been synchronized using the ledger entry

• Repeating this process for each ledger entry until the sequence number for the account data is equal to the sequence number for the most recent ledger entry, at which point the account data has been synchronized with the most recent transaction(s)

Because a subsequent transaction may cause the most recent ledger entry to be updated rather than the creation of a new ledger entry, the synchronization process described above may be initiated by decrementing the sequence number for the account data so that the final ledger entry is not used during the synchronization process. This allows subsequent updates to the final ledger entry to occur while the ledger entry remains available for future synchronization with the account. However, when a request to withdraw liquidity associated with the account is received, the final synchronization process that is performed may omit this step so that the most recent ledger entry is used to determine the current amount of liquidity for the account prior to attempting to transfer liquidity from the platform smart contract to the requesting wallet address.

Viewing Liquidity

To allow users to view amounts of liquidity associated with an account without changing the state of the platform smart contract, an interface may be provided that presents information from the contract obtained using read-only processes. In such a case, the synchronization process described above may be performed in memory to determine the information presented in the interface, but the ledger entries and account data associated with the read-only process may remain unchanged.

For example, when a request to view an amount of liquidity associated with an account is received:

• The account data associated with the requesting wallet address is accessed

• The ledger entry having the sequence number immediately following the sequence number associated with the account data is accessed

• The portion of the platform smart contract liquidity associated with the account is determined, as described above

• The portion of the change in liquidity for the ledger entry that is attributable to the account is determined, as described above

• A current amount of liquidity associated with the account data based on this change in liquidity and the amount of liquidity indicated in the account data is determined and stored in memory

  • Because the state of the platform smart contract is not changed, the account data is not updated and this value is instead stored in memory

  • The sequence number for the account data and the reference value for the ledger entry are also not changed for this reason

• This process is repeated for each ledger entry having a sequence number greater than that of the account data until each ledger entry has been used to update the stored value for the current amount of liquidity

• The determined amount is then displayed in an interface

Because the determination of an amount of liquidity to display in an interface is a read-only process, the state of the platform contract is not changed, and a synchronization process for one or more accounts would not be opportunistically performed in conjunction with this process.

Withdrawal of Liquidity

Withdrawal of liquidity associated with an account may operate similarly to the addition of liquidity. When a request to withdraw liquidity is received from a wallet address, account data for that wallet address is accessed. (Because withdrawal of liquidity requires an existing account having a positive amount of liquidity, a request to withdraw liquidity would fail if no existing account data indicating positive liquidity for that wallet address is present.)

Once the account data associated with a request is retrieved, a synchronization process may be performed. As described previously, if the sequence number for the account data is currently equal to that of the latest ledger entry, this indicates that the account has been previously synchronized using the most recent ledger entry. If the sequence number for the account data is not equal to that of the latest ledger entry, a synchronization process is performed to determine the current amount of liquidity associated with the account data using each ledger entry that has not yet been used to synchronize the account data.

After the synchronization process has been completed and the current amount of liquidity associated with the account has been updated, a determination may be made that the amount of liquidity associated with the account is greater than or equal to the requested amount of liquidity for withdrawal. If the amount of liquidity associated with the account data does not equal or exceed the requested amount, the request may fail and the account data may remain unchanged. If the amount of liquidity associated with the account data equals or exceeds the requested amount, the requested amount of liquidity may be transferred to the requesting wallet address, and the account data may be modified by subtracting the requested amount of liquidity from the current amount associated with the account data. A flag or value associated with the platform may then be updated to indicate that the liquidity amount associated with an account had changed so that when the next transaction occurs, a new ledger entry may be created rather than updating the most recent ledger entry.

In some cases, the platform may be configured to permit a request to withdraw all available liquidity to be submitted. Alternatively, the platform may be configured to only permit requests to withdraw all available liquidity associated with an account. In such cases, after the synchronization process has been completed, all liquidity associated with the account data may be transferred to the requesting wallet address, and the step of determining that the liquidity associated with the account data equals or exceeds that associated with the request may be omitted.

Optionally, because the withdrawal of liquidity from the platform smart contract is a transaction that resulted in a change in state of the platform smart contract, account data for one or more additional accounts may also be opportunistically synchronized. For example, a queue may be maintained, and the account data indicated at the top of the queue may be synchronized using any ledger entries that have not yet been used to synchronize the account data. That account data may then be placed at the end of the queue.

Configurable Parameters

Based on the intended use of the platform, the platform may be configured to limit the amount of liquidity that may be provided by a user in a single addition, the total amount of liquidity that may be associated with a single account, the total percentage of liquidity for the platform that may be associated with a single account, and so forth. It is also possible to restrict deposits to specific amounts of liquidity, such as a selected fixed amount, a set of fixed amounts (e.g., multiples of 1000), etc. Deposits of liquidity may also be time-limited, such as by restricting additions from the same wallet address to one addition per day, week, or other time period.

Similarly, the platform may be configured to limit the amount of liquidity that may be withdrawn in a single withdrawal, or as described previously, the platform may be configured to only permit withdrawals of all liquidity associated with an account. Withdrawals may also be limited to fixed amounts or sets of fixed amounts. Additionally, withdrawals may be time-limited. For example, after initiating a withdrawal, tokens may be accessed after passage of a selected period of time, such as five days.

Additions and withdrawals of liquidity may also be throttled, such as by restricting the number of liquidity transactions or attempted transactions that may occur within a selected period of time.

The platform may be configured to divide revenue associated with accounts. For example, a percentage of the revenue accrued by an account may be added to the account data for that account, while the remainder may remain separately accessible to the user associated with that account. As one example, liquidity indicated in the account data may be used to calculate revenue and expenditures associated with the account while the separately-accessible liquidity may not. Liquidity indicated in the account data may be withdrawn after a selected period of time, while the separately-accessible liquidity may be accessed immediately.

In a similar manner, portions of revenue or expenses may be routed for various purposes, sent to specific wallet addresses or smart contracts, used to fund other transactions, and so forth.

Transactions associated with the platform smart contract may be similarly limited. For example, a particular source of transactions, such as smart contract associated with a game of chance, may only be permitted to access a fixed amount of liquidity associated with the platform smart contract, or a selected percentage of the liquidity. Similarly, a source of transactions may be prevented from accessing the platform smart contract more than a selected number of times within a given time period.

Conclusion

We have proposed a platform for enabling a group of users to fund expenses and receive revenue from transactions associated with a platform smart contract. Using a system of ledger entries that record the changes in platform liquidity for each transaction, the liquidity associated with individual user accounts may be determined on an as-needed basis through an iterative synchronization process. This process is readily scalable and uses less time and computational resources compared to systems that continuously track amounts of liquidity associated with user accounts. Optimizations of this process, such as opportunistic synchronizing of accounts each time the platform smart contract changes state due to a transaction, and removal of ledger entries after each preexisting account has been synchronized using those entries further increases scalability and computational savings.