Waves Smart Asset Applicat ...

In the two previous articles we discussed using smart accounts and smart assets for running auctions and creating customer loyalty programs , as well as facilitating transparency for financial instruments.Today, we will look at some specific use cases for smart assets, including asset freezing and restricting transactions for certain addresses.Smart assets allow Waves users to apply scripts to tokens in much the same way as they can apply scripts to smart accounts. Whenever a transaction for a smart asset is created, it is validated by the script before being confirmed by the blockchain.Smart assets differ from smart accounts in the following ways:In a smart asset’s code, proofs cannot be checked (as discussed in the first article)In a smart account’s code, an ExchangeTransaction can only be checked if your account is a matcher account. Otherwise, only an order can be checked. In a smart asset’s code, you cannot check an order, but you can check an ExchangeTransaction and, if necessary, extract an order from it.Unlike a smart account, a smart asset doesn’t have a state, but we still have access to account states from the script.Smart assets help to substantially simplify the process of writing contracts, making implementation of many use cases more concise and elegant.Asset FreezingTo freeze assets until a certain block height, targetHeight, is reached, simply define this value in the following smart asset’s script:let targetHeight = 1500000height >= targetHeightheight is a language function that returns the current heightUsing a certain matcherTo define a certain matcher, you can assign the matcher address as the sender value in the following smart asset’s script:match tx {case t : ExchangeTransaction =>t.sender == addressFromString("3PJaDyprvekvPXPuAtxrapacuDJopgJRaU3")case _ => true}Recipient whitelistTo allow transfer of tokens only to specific accounts — to create a “whitelist” — you can use a smart asset with the following script, which checks for the presence of an address on the list:match tx {case t : TransferTransaction =>let trustedRecipient1 = addressFromString("3P6ms9EotRX8JwSrebeTXYVnzpsGCrKWLv4")let trustedRecipient2 = addressFromString("3PLZcCJyYQnfWfzhKXRA4rteCQC9J1ewf5K")let trustedRecipient3 = addressFromString("3PHrS6VNPRtUD8MHkfkmELavL8JnGtSq5sx")t.recipient == trustedRecipient1 || t.recipient == trustedRecipient2 || t.recipient == trustedRecipient3case _ => false}For purposes of security and provable completion of language, the list doesn’t complete implementation of the iterator. Therefore, it is defined as a set of specific elements.Recipient blacklistSimilarly, to prohibit transfer of tokens to specific accounts, you can create a blacklist. Exactly the same smart asset script will be used, but it will check an address for absence from the blacklist:match tx {case t : TransferTransaction =>let bannedRecipient1 = addressFromString("3P6ms9EotRX8JwSrebeTXYVnzpsGCrKWLv4")let bannedRecipient2 = addressFromString("3PLZcCJyYQnfWfzhKXRA4rteCQC9J1ewf5K")let bannedRecipient3 = addressFromString("3PHrS6VNPRtUD8MHkfkmELavL8JnGtSq5sx")t.recipient != bannedRecipient1 && t.recipient != bannedRecipient2 && t.recipient != bannedRecipient3case _ => false}Transferring by issuer permissionUsing a smart asset, you can also add the option of transferring the smart asset only with its issuer’s permission (commitment/debt label). The issuer expresses their consent by placing the transaction’s ID in their account’s state:match tx {case t : TransferTransaction =>let issuer = extract(addressFromString("3P6ms9EotRX8JwSrebeTXYVnzpsGCrKWLv4"))#checking that the issuer's state contains the current transaction's IDisDefined(getInteger(issuer, toBase58String(t.id)))case _ => false}Asset tradable only against a certain currencyA smart asset can allow trading solely against specific coins. For instance, to ensure the smart asset trades only with bitcoin, the following code can be used:let BTCId = base58'8LQW8f7P5d5PZM7GtZEBgaqRPGSzS3DfPuiXrURJ4AJS'match tx {case t : ExchangeTransaction =>t.sellOrder.assetPair.priceAsset == BTCId || t.sellOrder.assetPair.amountAsset == BTCIdcase _ => true}Trading with prices from an oracleIn a smart asset’s script, you can set permission for trading only at a price fixed in the trusted oracle’s state:let oracle = Address(base58'3PLNmokt22NrSiNvCLvwMUP84LCMJqbXwAD')let assetId = toBase58String(base58'oWgJN6YGZFtZrV8BWQ1PGktZikgg7jzGmtm16Ktyvjd')match tx {#prohibiting the transfer of the assetcase t: TransferTransaction | MassTransferTransaction => falsecase e: ExchangeTransaction =>#checking that trading is at the price fixed in the oracle's state for this assetlet correctPrice = e.price == extract(getInteger(oracle, assetId))#checking that the trading is in exchange for WAVESlet correctPriceAsset = !isDefined(e.sellOrder.assetPair.priceAsset)correctPrice && correctPriceAssetcase _ => true}Here, we face a special situation while checking the ID of the asset against which our smart asset trades. If the asset’s ID is not defined, it is WAVES by default. In the script, we check that trading is to be against WAVES.Fixed price raiseYou can set a fixed price for a smart asset, which can be raised in steps by a specific proportion. This is an example of a script for a smart asset traded with a fixed price that is raised by 5% every 1,000 blocks:let startPrice = 10let startHeight = 1000let interval = 1000#by what percentage the price is increased in one steplet raise = 5match tx {case t: TransferTransaction | MassTransferTransaction => falsecase e: ExchangeTransaction =>e.price == startPrice + ((height - startHeight) / interval) * (100 + raise) / 100&& !isDefined(e.sellOrder.assetPair.priceAsset)case _ => true}Interval tradingA script can also be applied to allow trading of a smart asset that is limited to a predetermined time frame. This is an example of such a script:let startHeight = 10000let interval = 44000let limit = 1500match tx {case t: TransferTransaction | MassTransferTransaction | ExchangeTransaction =>(height - startHeight) % interval < limitcase _ => true}In the script, we check that no more than “limit” of intervals has elapsed since the start of trading (startHeight). The interval length equals the number of blocks defined in the interval field.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves Smart Asset Applications: Whitelists, Blacklists and Interval Trading was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tradisys Re-Launches Fhlos ...

In the new version of the blockchain game, which is inspired by the movie ‘Fifth Element,’ the chances of winning will be much higher.Do you remember the blockchain game Fhloston Paradise, which Tradisys launched on the Waves blockchain a few weeks ago? The community really enjoyed the game, which was designed to test players’ patience.The winner of the original game was Dmitry Pichulin, known by the nickname @deemru. His recipe for success was to use Patrollo, an open-source bot he developed specifically for the game. Patrollo paid just eight stakes of 1 WAVES, eventually winning 4,700 WAVES for Dmitry.We’ll soon publish an interview with the winner, but you can already check out the bot, which is available on GitHub.Now, Tradisys has come up with a new version of the game, which promises to be even more exciting.While the original game functioned on the principle of indefinite extension, the new version will be broken into rounds.At the beginning of each round, players will have 15 blocks to extend the round.Each round can last a maximum of 1,240 blocks, which roughly corresponds to 21 hours. The current block height will be displayed, so players will be able to see how many blocks are left before the end of the round.Once a round is over, the winner — the player who paid the last stake — will have 200 blocks (roughly three hours) to collect the prize. During those 200 blocks, no new stakes can be paid.If a round ends earlier than 1,240 blocks, the game is frozen until 1,440 blocks have elapsed since the beginning of the round. The remaining time can be used by the winner to collect their prize.If the winner fails to collect their prize, that amount will be transferred to the subsequent round.As a result, there will be a new winner every day, as opposed to just one main winner as there was in the first version of the game. The chances of winning will therefore be considerably higher, making the game much more exciting!You can also try out Dmitry’s bot. Let it play on your behalf — maybe it will win for you!Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditTradisys Re-Launches Fhloston Paradise was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

RIDE for dApps hits Waves ...

The upgrade to Waves’ native blockchain language is a key step along the way to full dApp implementation and Web 3.0 development.Earlier in January we released our roadmap. We have now reached the first milestone on this, and the release of Node update 0.17 brings RIDE for dApps to TestNet!As we’ve discussed at length before, blockchain really isn’t designed for carrying out complicated computations. Blockchain architecture simply isn’t suited to this. After seeing the vulnerabilities and edge cases that have arisen on Ethereum, Waves has always maintained that Turing-completeness should not be essential for on-chain blockchain computations. The RIDE language itself is deliberately non-Turing complete for this reason. However, Turing complete computations can still be achieved by spreading operations over consecutive blocks, if such functionality is required. RIDE therefore offers a flexible but safe solution for on-blockchain computation.RIDE for dApps is being introduced to grant an account a way of assigning a programmable function to itself, with callable functions that are able to:Receive paymentsChange the account’s stateSend WAVES and tokens from the accountTo initiate the call, we have added a new command: InvokeScriptTransaction. This needs to be put on the blockchain to call a function, and the sender pays fees to the miner for the invocation to be executed. The sender can optionally attach payment in WAVES or tokens, and upon invocation the contract state can be changed and the contract can make multiple payments.The existing mechanics for authorisation scripts will be maintained under the @Verifier function of the account. This can be thought of as an ‘admin’ function for the contract’s owner or owners. By default, the contract, contract data and contract tokens are all controlled by the private key for the account. Multisig control is possible. If @Verifier is always false, then the contract is sealed — immutable.We will now give an overview of some of the use cases that this new functionality makes possible. As we know, these functions can generate transfers (transfer of funds from the contract address) and change a dApp’s state (via DataTransactions from the contract account). Moreover, RIDE for dApps makes implementation of certain use cases far easier and more convenient.Dividing funds into two equal partsSuppose we need to implement a mechanism to split the funds in an account equally between two specific addresses.Consider an implementation using a smart account: the script allows the account to send only MassTransfer transactions that meet the specified conditions:There are two recipients: Alice and BobFee = 0.006 WAVESEach of them is sent exactly ((balance-fee) / 2) WAVESThe account can only send a transaction that meets the conditions described above. Other transactions will not be accepted on the blockchain.# Predefined addresses of recipientslet Alice = base58'3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8let Bob = base58'3N78bNBYhT6pt6nugc6ay1uW1nLEfnRWkJd'match(tx) {# only MassTransferTransactions are allowedcase tx : MassTransferTransaction =># check if the transaction has exactly two predefined recipientstx.transferCount == 2&& tx.transfers[0].recipient == Alice&& tx.transfers[1].recipient == Bob# check if WAVES are distributed evenly&& tx.assetId == unit&& tx.transfers[0].amount == (wavesBalance(tx.sender) - fee) / 2&& tx.transfers[0].amount == tx.transfers[1].amount# check if the fee is equal to 0.006 WAVES&& tx.fee == 600000# the other types of transactions are prohibitedcase _ => false}In RIDE 4 dApps we do this differently: you can divide the funds between two given addresses by calling the ‘split’ function described in the script. This function divides all the funds of the account-contract in half, sending them to two addresses — Alice and Bob. You can call this function by sending InvokeScriptTransaction. In this case, the fee is paid by the one who sends the transaction, so you do not need to check the fee in the script code.# predefined addresses of recipientslet Alice = base58'3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8'let Bob = base58'3N78bNBYhT6pt6nugc6ay1uW1nLEfnRWkJd'@Callable(i)func split() = {# calculate the amount of WAVES that will be transferred to Alice and Boblet transferAmount = wavesBalance(this) / 2# the result of a contract invocation contains two transfers (to Alice and to Bob)TransferSet(List(ContractTransfer(Alice, transferAmount, unit),ContractTransfer(Bob, transferAmount, unit)))}Register of addresses that have paid for a serviceImagine that we want to create a service that allows you to register payment for services by users (for example, a monthly subscription). Subscribers each pay 10 WAVES, with the time of the last payment being entered into the register.Consider the implementation using a smart account. The account script only allows DataTransactions that meet the following conditions:0.005 WAVES feeTwo entries<transfer_id> : “used”<payment_sender_address> : <current_height>3. In the proofs array, the first element is the transfer transaction id (payment for services), which includes:The recipient address for the contractAmount >= 10 WAVES + 0.005 WAVES (to pay for DataTx fee)Id was not previously used as a key (to prevent double-spending)# fixed payment and fee valueslet dataTxFee = 500000let paymentAmount = 1000000000match (tx) {# only DataTransactions are allowedcase t: DataTransaction =># extract the payment transaction's id from the DataTransactionlet paymentTxId = toBase58String(t.proofs[0])# extract the provided payment transaction from the blockchainlet paymentTx = transactionById(fromBase58String(paymentTxId))match (paymentTx) {# the provided payment transaction should be a TransferTransactioncase paymentTx : TransferTransaction =># check if the payment transaction was not used before (to prevent double-spending)&& !isDefined(getString(this, paymentTxId))# check if the payment recipient is this account&& paymentTx.recipient == this# check if the transfer amount exceeds the required minimum&& paymentTx.amount >= paymentAmount + dataTxFee# check if the transferred asset is WAVES&& paymentTx.assetId == unit# check if the data satisfies the specified format&& size(t.data) == 2&& getString(t.data, paymentTxId) == "used"&& getInteger(t.data, toBase58String(tx.sender.bytes)) == height# check if the fee is correct&& t.fee == dataTxFeecase _ => false}# the other types of transactions are prohibitedcase _ => false}The main disadvantage of this approach is the complex mechanics: you need to send two transactions, one of which refers to the other, as well as send transactions on behalf of other account (specify the sender address of the contract).Using RIDE for dApps everything is much easier. The payment can be attached to InvokeScriptTransaction. We need only check in the script that the payment was attached. If the address calling the script pays at least 10 WAVES, it is entered into the registry.# fixed payment amountlet paymentAmount = 1000000000@Callable(i)func pay() = {# check if the attached payment is at least 10 WAVESlet payment = extract(i.payment)if (payment.asset != unit || payment.amount < paymentAmount)then throw("You have to provide a payment of at least 10 WAVES")# the result of a contract invocation contains one dataEntry(<caller_address>, <current_height>)else WriteSet(List(DataEntry(toBase58String(i.caller.bytes), height)))}VotingIn this example, a non-anonymous vote is implemented based on known voting lists and candidates. An account ballot is prepared in advance (sent to the list via DataTransaction), including:The list of voters (for each voter create an entry { <voter_address_voted>, false })The list of candidates (for each candidate create an entry { <candidate_address>, 0 }).To implement using a smart account, the account script allows only DataTransactions:Submitted by voters who have not already voted. The voter’s public key goes in proofs[1] and signs this DataTransactions (the signature itself goes in the proofs[0]).The DataTx contains exactly two entries:<candidate> : <current_value> + 1<voter_address_voted> : truematch(tx) {# only DataTransactions are allowedcase tx : DataTransaction =># extract the chosen candidate from the transactionlet candidate = tx.data[0].key# check if the transaction was signed by the voterlet voterPublicKey = tx.proofs[1]let voterKey = toBase58String(addressFromPublicKey(voterPublicKey)) + "_voted"sigVerify(tx.bodyBytes, tx.proofs[0], voterPublicKey)# check if the voter has not voted yet&& extract(getBoolean(this, voterKey)) == false# check if the data satisfies the specified format&& size(tx.data) == 2&& extract(getInteger(tx.data, candidate)) == extract(getInteger(this, candidate)) + 1&& extract(getBoolean(tx.data, voterKey)) == truecase _ => false}In RIDE for dApps, in the contract script we describe the vote function, which can be called to vote for a certain candidate.@Callable(i)func vote(candidate : String) = {let voterKey = toBase58String(i.caller.bytes) + "_voted"# check if the caller is registered as a voterif (!isDefined(getBoolean(this, voterKey))) then throw("You are not registered as a voter")# check if the voter has not voted yetelse if (extract(getBoolean(this, voterKey)) == true) then throw("You have already voted")# check if the candidate is in the voting listelse match (getInteger(this, candidate)) {case r : Integer =>WriteSet(List(DataEntry(candidate, r + 1),DataEntry(voterKey, true)))case _ => throw ("Candidate is not in the voting list")}}WalletIn this example, a dApp wallet is implemented: you can send a WAVES payment, and it will save it in the wallet (deposit function), and you can take deposited WAVES back out of the wallet (withdraw function).func getBalance(address: Address) : Int = {match getInteger(this, toBase58String(address.bytes)) {case a: Int => acase _ => 0}}@Callable(i)func deposit() = {let caller = toBase58String(i.caller.bytes)let currentBalance = getBalance(caller)let payment = match(i.payment) {case p : AttachedPayment => pcase _ => throw("You have to provide a payment to deposit")}if (payment.asset != unit) then throw("This wallet cannot hold assets other than WAVES")else {let newBalance = currentBalance + payment.amountWriteSet(List(DataEntry(caller, newBalance)))}}@Callable(i)func withdraw(amount: Int) = {let caller = toBase58String(i.caller.bytes)let currentBalance = getBalance(caller)if (amount < 0) then throw("Can't withdraw negative amount")else if (amount > currentBalance) then throw("Insufficient balance")else {let newBalance = currentBalance - amountContractResult(WriteSet(List(DataEntry(currentKey, newBalance))),TransferSet(List(ContractTransfer(i.caller, amount, unit))))}}ExchangerThis example shows implementation for a dApp-exchanger, which buys/sells WAVES and USD at a fixed price. It describes the functions ‘buyWAVESforUSD’ and ‘sellWAVESforUSD’. Users need to attach payment, and the dApp sends a transfer in response.let WAVES = unit # amount assetlet USD = base58'Ft8X1v1LTa1ABafufpaCWyVj8KkaxUWE6xBhW6sNFJck' # price assetlet buyPrice = 301let sellPrice = 299let scale = 100000000@Callable(i)func buyWAVESforUSD() = {let payment = extract(i.payment)if (payment.asset != USD) then throw("To buy WAVES for USD you have to provide USD")else {let amount = payment.amount * scale / buyPriceTransferSet(List(ContractTransfer(i.caller, amount, USD)))}}@Callable(i)func sellWAVESforUSD() = {let payment = extract(i.payment)if (payment.asset != WAVES) then throw("To sell WAVES for USD you have to provide WAVES")else {let amount = payment.amount / (scale / sellPrice)TransferSet(List(ContractTransfer(i.caller, amount, WAVES)))}}This is by no means a complete list of possible use cases. Check out RIDE for dApps on TestNet and let us know your thoughts and your own use cases!Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditRIDE for dApps hits Waves TestNet! was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Application of Waves Smart ...

In the previous article, we considered several use cases for smart accounts in business, including auctions and customer loyalty programs.Today, we will discuss how smart accounts and smart assets could improve the transparency and reliability of financial instruments such as options, futures and bills of exchange.OptionsAn option is a contract that gives the buyer the right but not the obligation to buy an asset at a specified price, prior to or on a certain date.An option can be implemented in the following way. We use a smart asset for an option and a smart account for a participant who takes the role of an exchange and issues options (“exchange” participant). The “exchange” participant pledges to sell a certain amount of an asset at sellPrice between block heights expirationStart and expirationEnd.In the smart asset’s code, we just need to check that it trades only between the set heights, while responsibility for observing the rules will be delegated to the “exchange” participant’s code.Smart asset code:let expirationStart = 100000let expirationEnd = 101440match tx {case some : ExchangeTransaction | TransferTransaction =>height > expirationStart && height <= expirationEndcase _ => false}We’ll assume that the following actions will take place: the “exchange” participant sells options for buying a certain asset, and the other participants can send or trade these options. To execute their right to buy the asset, a potential buyer has to transfer a corresponding number of options to the buyer’s account — i.e. to the account of the “exchange” participant.Subsequently, the buyer adds the information on the transfer to the account’s state, and only after that can an ExchangeTransaction with specified conditions for buying/selling be accepted by the blockchain.In the smart account code, we need to check that any ExchangeTransaction going through it for the final deal corresponds to the set conditions and the buyer purchases only the same number of units they sent to the account of the “exchange” participant.The buyer needs to send a correct DataTransaction with the transfer, so that the “exchange” participant can avoid double spending. In this DataTransaction, the buyer adds to the key, which corresponds to their address, a value that is equal to the number of options transferred to the account of the “exchange” participant, i.e. equal to the number of units of the asset they can buy.Smart account code:#the account owner pledges to sell a certain number of the asset's units#at sellPrice between block heights expirationStart and expirationEndlet expirationStart = 100000let expirationEnd = 101440let sellPrice = 10000let amountAsset = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'let priceAsset = base58'9jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'#option asset IDlet optionsAsset = base58'7jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'#extracting the sender's address from the transactionlet this = tx.sendermatch tx {case dataTx : DataTransaction =>#extracting the number of units from the DataTransaction by the key (user ID)let units = extract(getInteger(dataTx.data, dataTx.data[0].key))#extracting the transaction from the prooflet e = transactionById(o.proofs[7])match e {case exchangeTx : ExchangeTransaction =>let correctSeller = exchangeTx.sellOrder.sender == Boblet correctBuyer = exchangeTx.buyOrder.sender == Alicelet correctAssetPair = (exchangeTx.sellOrder.assetPair.amountAsset == amountAsset && exchangeTx.sellOrder.amount == sellAmount && exchangeTx.sellOrder.price == sellPrice)|| (exchangeTx.buyOrder.assetPair.amountAsset == amountAsset && exchangeTx.buyOrder.amount == sellAmount && exchangeTx.buyOrder.price == sellPrice)#making sure that the order’s ID is correctly stated in the proof transactionlet correctProof = extract(getBinary(extract(tx.sender), toBase58String(exchangeTx.sellOrder.id))) == o.id|| extract(getBinary(extract(tx.sender), toBase58String(exchangeTx.buyOrder.id))) == o.idcorrectAssetPair && correctProof && correctSeller && correctBuyercase _ => false} &&(height >= expiration) &&#verifying the signature(sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)) &&(tx.sender == Bob)case _ => false}Futures contractsUnlike options, futures contracts (futures) represent the buyer’s obligation to buy an asset at a predetermined price at a specified time in the future, not merely the opportunity to do so.Overall, the implementation of futures is similar to that of options. Here, a smart asset acts as the futures.We also need to check that both buyer and seller sign a transaction order. A futures contract is an obligation that has to be executed in any case. So, if the buyer or seller repudiate their obligations, any participant in the network can send a transaction and thereby execute the contract.The smart asset’s script controls all TransferTransactions and ExchangeTransactions of the futures assets, approving them only if the buyer has created an order for a future purchase of the future assets from the “exchange” participant.This order has to be valid and meet the conditions under which the futures contract was issued. To check the order, all of its fields could be recorded to the buyer’s account’s state along with the byte code of the signed order, after which validation by a third party could be carried out.Currently, RIDE doesn’t contain a native feature for parsing transaction bytes, but has all the necessary tools for its implementation. Developers could therefore try to implement that feature by themselves.Multi-signature accounts / EscrowA multi-signature account allows several users to jointly manage assets (for instance, transactions with assets could only be allowed if signed by three users out of four). To create multi-signature accounts with RIDE, we can use transaction proofs.A multi-signature account could also be used for an escrow account, in which funds are held until transacting parties have satisfied their contractual obligations.let alicePubKey = base58'5AzfA9UfpWVYiwFwvdr77k6LWupSTGLb14b24oVdEpMM'let bobPubKey = base58'2KwU4vzdgPmKyf7q354H9kSyX9NZjNiq4qbnH2wi2VDF'let cooperPubKey = base58'GbrUeGaBfmyFJjSQb9Z8uTCej5GzjXfRDVGJGrmgt5cD'#checking who provided correct signatureslet aliceSigned = if(sigVerify(tx.bodyBytes, tx.proofs[0], alicePubKey)) then 1 else 0let bobSigned = if(sigVerify(tx.bodyBytes, tx.proofs[1], bobPubKey)) then 1 else 0let cooperSigned = if(sigVerify(tx.bodyBytes, tx.proofs[2], cooperPubKey)) then 1 else 0#adding all correct signatures and checking their numberaliceSigned + bobSigned + cooperSigned >= 2Token curated registry (TCR)Many blockchain platforms face the problem of toxic assets. For instance, on Waves Platform, any address that has paid the issuance fee can create an asset.One way to approach the toxic asset issue is with a token curated registry (TCR), generated by token holders.To vote to add a specific token to the list, holders place a stake corresponding to their share in the total number of issued tokens. A token is added to the registry if the majority of its holders vote for it.In our example, a user is allowed to add a token to the consideration list (during the “challenge” period) by the state key = asset_name solely if the current value of the count = 0.Also, the user has to have an non-zero balance of the token in question in their wallet. Then, during the voting period, the user can vote for each asset in their wallet, but just once, rating them on a scale from 1 to 10. Users’ votes are represented by keys that look like this: user_address+assetID.let asset = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'let addingStartHeight = 1000let votingStartHeight = 2000let votingEndHeight = 3000#extracting the sender’s address from the transactionlet this = extract(tx.sender)#extracting the address from the transaction’s prooflet address = addressFromPublicKey(tx.proofs[1])match tx {case t: DataTransaction =>if(height > addingStartHeight)then(if(height < votingStartHeight)then(#adding#checking if this address has this assetlet hasTokens = assetBalance(address, asset) > 0size(t.data) == 1#making sure this assets has not yet been added&& !isDefined(getInteger(this, toBase58String(asset)))#checking if 0 has been added by the asset key&& extract(getInteger(t.data, toBase58String(asset))) == 0&& hasTokens)else(if(height < votingEndHeight)then(#voting#finding out the current number of votes for this asset and the base numberlet currentAmount = extract(getInteger(this, toBase58String(asset)))let newAmount = extract(getInteger(t.data, toBase58String(asset)))let betString = toBase58String(address.bytes) + toBase58String(asset)#checking that this address has not yet voted for this assetlet noBetBefore = !isDefined(getInteger(this, betString))let isBetCorrect = extract(getInteger(t.data, betString)) > 0&& extract(getInteger(t.data, betString)) <= 10#checking if the voter has enough tokenslet hasTokens = assetBalance(address, asset) > 0#checking that the transaction is defined correctlysize(t.data) == 2 && isDefined(getInteger(this, toBase58String(asset)))&& newAmount == currentAmount + 1&& noBetBefore && isBetCorrect && hasTokens)else false) && sigVerify(tx.bodyBytes, tx.proofs[0], tx.proofs[1]))else falsecase _ => false}Subscription feeIn this example, we look at using smart accounts for executing a “subscription fee” — regular payments for goods or services in a set time frame.If a user sends to a smart account (through transaction proofs) an ID TransferTransaction with a required amount of transferred funds, they could add to the account state: {key: address, value: true}.This would mean that that the user confirms a subscription for goods or services. When the subscription period expires, any user in the network could change that value to false.let subscriptionPeriod = 44000let signature = tx.proofs[0]let pk = tx.proofs[1]let requiredAmount = 100000#extracting the sender’s address from the transactionlet this = extract(tx.sender)match tx {case d: DataTransaction =>#extracting the date of the most recent paymentlet lastPaymentHeight = extract(getInteger(this, d.data[0].key + "_lastPayment"))size(d.data) == 1 && d.data[0].value == "false" && lastPaymentHeight + subscriptionPeriod < height||(let address = d.data[0].key#extracting the transfer transaction by the ID indicated in the proofs.let ttx = transactionById(d.proofs[0])size(d.data) == 2&& d.data[0].value == "true"&& d.data[1].key == address + "_lastPayment"&& match ttx {case purchase : TransferTransaction =>d.data[1].value == transactionHeightById(purchase.id)&& toBase58String(purchase.sender.bytes) == address&& purchase.amount == requiredAmount&& purchase.recipient == this#making sure the asset is WAVES&& !isDefined(purchase.assetId)case _ => false})case _ => false}VotingSmart accounts could be used for implementing voting on the blockchain. One example is voting for the best ambassador’s report in an ambassador program. The account state is used as a platform to record votes for various options.In this example, only those who have purchased “voting” tokens can vote. A user sends a DataTransaction with (key, value) = (purchaseTransactionId, buyTransactionId). Other values for this key are not allowed. Using their address and voting option, a DataEntry can be done only once. Voting is allowed only within a specified period.let asset = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'let address = addressFromPublicKey(tx.proofs[1])let votingStartHeight = 2000let votingEndHeight = 3000#extracting the sender’s address from the transactionlet this = extract(tx.sender)match tx {case t: DataTransaction =>(height > votingStartHeight && height < votingEndHeight) &&#verifying that the signature of the transaction is correctsigVerify(tx.bodyBytes, tx.proofs[0], tx.proofs[1]) &&#verifying that the user puts his vote next to his addressif (t.data[0].key == toBase58String(address.bytes))then (#extracting the transaction for transfer of a voting token from the prooflet purchaseTx = transactionById(t.proofs[7])match purchaseTx {case purchase : TransferTransaction =>let correctSender = purchase.sender == t.senderlet correctAsset = purchase.assetId == assetlet correctPrice = purchase.amount == 1let correctProof = extract(getBinary(this, toBase58String(purchase.id))) == t.idcorrectSender && correctAsset && correctPrice && correctProofcase _ => false})elsesize(t.data) == 1 && !isDefined(getBinary(this, t.data[0].key))case _ => false}Bill of exchangeA bill of exchange is a written order under which one party is obliged to pay a fixed sum of money to another party on demand or at a predetermined date.In our example, a smart account is used, the expiration date of which corresponds to the payment date of the bill of exchange.let expiration = 100000let amount = 10let asset = base58'9jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'let Bob = Address(base58'3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8')let Alice = Address(base58'3PNX6XwMeEXaaP1rf5MCk8weYeF7z2vJZBg')match tx {case t: TransferTransaction =>(t.assetId == asset)&&(t.amount == amount)&&(t.sender == Bob)&&(t.recipient == Alice)&&(sigVerify(t.bodyBytes, t.proofs[0], t.senderPublicKey))&&(height >= expiration)case _ => false}DepositA deposit is the placement of funds at a bank under certain conditions (duration, interest rate). In our example, a smart account acts as a bank. After reaching a certain block height, which corresponds to the period of the deposit, a user can have their cash repaid with interest. In the script, a block height is set, after which the user can withdraw the deposited amount (finalHeight).heightUnit is the number of blocks in one period unit (such as a month or a year). Initially, we check the presence of a record with the pair (key, value) = (initialTransferTransaction, futureDataTransaction). Then, the user has to send a TransferTransaction with correct information on the deposited sum and interest collected over the deposit period. This information is checked against the initial TransferTransaction, which is contained in the current proof of the TransferTransaction. depositDivisor is the inverse of the deposit share (if the deposit is placed at a 10% interest, the share is 0.1 and depositDevisor equals 1/0.1 = 10).let this = extract(tx.sender)let depositDivisor = 10let heightUnit = 1000let finalHeight = 100000match tx {case e : TransferTransaction =>#extracting the height of the transaction by the transaction ID, which is in the seventh prooflet depositHeight = extract(transactionHeightById(e.proofs[7]))#extracting the deposit transactionlet purchaseTx = transactionById(e.proofs[7])match purchaseTx {case deposit : TransferTransaction =>let correctSender = deposit.sender == e.sender#checking that the user transfers to himself the correct sum of the deposit and the interestlet correctAmount = deposit.amount + deposit.amount / depositDivisor * (height - depositHeight) / heightUnit == e.amountlet correctProof = extract(getBinary(this, toBase58String(deposit.id))) == e.idcorrectSender && correctProof && correctAmountcase _ => false}&& finalHeight <= heightcase _ => sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)}In the third and final article in this series, we will look at some specific use cases for smart assets, including asset freezing and restricting transactions for specific addresses.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditApplication of Waves Smart Accounts and Smart Assets for Financial Instruments was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves Reward Token airdrop ...

The token includes smart features and will be used by the community to thank our Ambassadors!We recently launched the Waves Reward Token programme. WRT is a special token that the community can use to thank some of the most influential and helpful members of the Waves ecosystem. As you may be aware, this token is also a calling card for some of the features that Waves’ smart assets can provide. For example, the attached script will ensure that only Ambassadors themselves can sell WRT. The tokens will only be redeemable with the Waves team.Airdrop reportLast week we issued a total of 1,744,400 Waves Reward Tokens. We dropped half of these — 872,200 WRT — to the 8,722 Waves addresses that contained at least 10 Waves Community Tokens. The remaining 872,200 were sent to the Waves team for future distributions.Reward your Ambassadors!We are in the process of compiling a list of Waves Ambassadors. Those on the list can be rewarded using WRT today. (Each time we include a new Ambassador, the script whitelist needs to be updated, so please bear with us as we add further members.) Some of our current Ambassadors include:Aleksandr Beloussov, Tallinn, EstoniaAleksandr has been with us for a year and a half and has done so many useful things for the platform that we cannot list them all here! (And no doubt you are already familiar with his work.) We would like to express our gratitude to Aleksandr for his contributions and hope that others like him will join us!Wallet: 3PKnYbrB3Ut3iyiMoLbugPAUqt4nWQSJBCHIrlan Pierre, Rio de Janeiro, BrazilIrlan is the founder of Waves’ Brazilian Community, and has attended several events in different regions of Brazil to spread the word about Waves. Thank you, Irlan!Wallet: 3PDEnVbcLhsYbssbLbo3mHCwZYPAxD9JQQZAleksei Pupyshev, St.Petersburg, RussiaAleksei is a consultant, tech advisor in the field of intelligent & decentralised systems, engineer and public speaker. He is also the founder, architect and CEO of Ventuary Inc, a decentralised reviews and ratings platform and consulting agency. He is the founder of, and instructor at, the Blockchain Education Club. He has Engineering/AI/Big Data management experience through his work at Wrike Inc. and MailRu Group.Wallet: 3P9jA8yJH1wLso6vVC4VqEC5j8QAQ4kFdfDToko Satoru, Tokyo, JapanToko comes from Tokyo, Japan, and is passionate about technology — especially blockchain. He has worked in the IT industry for many years, starting his career at Softbank in 2012 as an IT Solutions Consultant for enterprise clients in the financial sector, before working for several startups and SMEs. In 2017, Toko joined the International and Japanese Cryptocurrency and Blockchain projects as a volunteer, advisor, and translator. More recently, he established www.heros.studio to support international projects expanding their operations into the Japanese market.Wallet: 3PFqte55VmWVKazeeA3yHaSKKMH8uaDaJaiShaun Biggs, London, UKShaun Biggs, known by many as ‘biggzi’, is a blockchain and Waves enthusiast from London, UK. He has a varied background in Business and IT, and first got involved in blockchain back in 2013 when he set up his own bitcoin mining farm.Shaun has contributed to and helped promote Waves activities since its inception. He is well-known on Twitter and Facebook for sharing Waves-focused content, writing blogs and articles, featuring on podcasts and producing YouTube videos, as well as assisting with events and meetups. Shaun has consulted on Waves with a number of startups looking for blockchain partners, and assisted many new users in learning about Waves.Wallet: 3PKPNTzQiQjqxSUqQ5vUUpDrcEdZrNqXuuMMario Spercz, Warsaw, PolandMariusz Sperczyński represents the Blockchain Alliance, a Polish organisation well-known for its educational activity covering a wide range of topics around all aspects of decentralised systems and the surrounding industry. BA focuses its efforts on five areas of cooperation: education, research, prototyping, community and start-ups, as well as the recently-developed area of ​​implementation of enterprise blockchain solutions. See www.blockalliance.io/ for more details.Wallet: 3P9fJjn7Wekh9oYikoRsLMT78ahUJrWi62bDavid Plaut, Perth, AustraliaDavid is a Business Advisor with over 12 years of experience, helping predominantly small business owners minimise their tax costs, assisting with compliance, and providing digital transformation advisory and business strategy advisory services. David is a member of the Institute of Chartered Accountants for Australia and New Zealand, as well as the Taxation Institute of Australia. He is also a Microsoft Flow enthusiast and has created a MS Flow Connector & Mobile Notification for Waves, which can be found here and here.Wallet: 3P5XssF5utyr6iwoE8igARCcasFCoDwMSAQAlan Li, Hong Kong, ChinaAlan is an active member of the Hong Kong blockchain community and has played a significant role in the adoption and application of blockchain technology. He has 10 years’ experience in software consulting, digital marketing and e-commerce. He is the local Ambassador for Waves Platform, holding meetups and introducing blockchain technology to the local community. In addition, he manages our Chinese-speaking community.Wallet: 3P3rBo2sVzKZQvbQponRFWXmocCNSL4hGPXOrkhan Ahmadov, Baku, AzerbaijanOrkhan is a businessman from Azerbaijan and an active Waves Ambassador. He has organised around 10 meetups on blockchain, at which Waves Platform and other technologies were discussed. He also organised the Blockchain Conference Azerbaijan and the Blockchain Workshop in 2018, and first ever Blockchain Hackathon Baku in 2019.Wallet: 3PLkctrmnUGje5Pvnv9AC95bE1Vw3xbeckzYou can find the full list of Ambassadors here: https://docs.google.com/spreadsheets/d/1mM4QlCaU6e6DsjJIE-AAMVIqMlx8a1d0ggsmdzbVAjA/edit?usp=sharingWhat next?After a successful launch of the Ambassadors’ programme and WRT, we plan to expand the scope of both. Applications are now open for new Ambassadors. We will also be rewarding other influencers and content creators with WRT.Ideal candidates will have a collection of different skills and experience.Business & social media Ambassadors:Business development skillsSocial media skillsBackground in finance, gaming, IT, consulting or legal sector (desirable)Excellent at networkingKnowledge of Waves products and techFluent EnglishPublic speaking and pitching skillsEvent organisation experienceStrong communication skills and IT fluencyTech ambassadors:Extensive knowledge of Waves techBlockchain development experienceEstablished GitHub repoHackathon experienceTeaching experience (seminars, webinars, etc)To apply, visit https://airtable.com/shrGixQXilTuMwPx4.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves Reward Token airdropped to WCT holders was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Web3.0: the road ahead for ...

Web3.0: the road ahead for Waves — Waves PlatformWeb3.0: the road ahead for WavesIt’s the right time to kick-start the next iteration of the web, with smart, decentralised digital services powered by blockchain and the new technologies Waves is building.The concept of decentralization is, as a matter of fact, quite new. Surprisingly, it was first formulated around the 19th century, together with the concept of centralization itself. Before that time people did not really give much thought to the general principles of the things they built, be it society’s structure or technology. Creation of huge nation states drew attention to the general principles of society structure, and brought about suspicion that rigid vertical structures had their own drawbacks. Rigid hierarchy and chain of command do make a lot of sense in many situations, but this always creates centralized point of failure, making systems vulnerable and corruptible.In the late 20th century technology started to have an overwhelming effect on the development of society. Computer networks became the veins through which society’s blood flows; tech that we build has a huge impact on the society we live in. The concept of decentralized technology started to take shape in the late 70s, in the form of distributed computing and consensus research.The real breakthrough, at least in people’s minds, came with blockchain technology. For the first time in the history of human technology we were able to create truly decentralized systems controlled only by the protocol we feed into them. Blockchain is now more than 10 years old, and although we can’t do all the things we want with it just yet, we can do enough to try and go beyond prototypes and working use-cases. Mass adoption, that Holy Grail of any emerging technology, must be found ASAP, since the time has come. WEB2.0 corporations have come to hold too much power. We did not notice how they gained access to tons of sensitive and valuable big data, and now we have the kind of monopoly that just can’t last.WEB3.0, the concept which emerged at the end of the last century, is finally shaping up in the first real products that unify a host of different technologies (Big Data, AI, IoT…) on a decentralized footing. To kick-start the revolution it is of vital importance to create retail WEB3.0 products and working enterprise applications now. We need to go beyond the crypto-community to make the ideas that emerged within it truly work.We can’t achieve full decentralization just yet, and actually we might never achieve it. To make WEB3.0 a really useful concept we need to understand that the end-goal of WEB3.0 is the creation of robust, transparent, synergetic systems by any means necessary. Decentralizing critical business logic and using centralized tech where we can’t do without it (storage, complicated computation), we are able to create products that can gain mass adoption now, where there’s a real need in a new approach in the systems we are building. Data storage can be enhanced and allow for privacy protection. It’s time to get down to some fancy and sophisticated cryptography, such as homomorphic encryption, and really make it work. In the near future, I’m sure, we’ll also be able to use verifiable computation, using which one can outsource computation to third-parties and obtain verifiable results.The decentralized layer, of course, has to be improved to solve scalability issues that riddle blockchain systems now. Waves’ RIDE smart contracts language update will provide a new approach to decentralized computation and business logic, which is closer to the nature of blockchain systems. It will be on the Waves mainnet by June. Waves-NG maximizes what you can get from on-chain transactions in terms of speed. To go further you need either to move off-chain or create custom sidechains, that process specific sets of transactions. The second approach is closer to our philosophy of getting the maximum from the current technology before moving forward, and it will be implemented in the second half of 2019. Future systems may (and probably should) give up on total network synchronization completely, but there’s still a long way to go, and the current technology is mature enough to disrupt WEB 2.0 architecture.The gateway to our WEB3.0 world is going to be our Waves Keeper. Storing private keys user-side and not trusting any sensitive data to third parties is the key to WEB3, and Keeper does exactly that.The next architecture level is the Decentralized Business logic layer. Sensitive business logic running on smart contracts, encrypted important private data, monetization through tokenization — it all goes there. Going deeper we arrive at the Centralized Layer, which soaks up WEB3 ideas as well — data is encrypted, computation is verifiable.Based on this architecture we’re building several applications now, with mass adoption in mind.They tap into diverse markets but are unified by the ideas of tokenization, being accessible to a mass audience, and providing an unparalleled level of transparency.We are building a decentralized voting platform. This is one of the most promising directions for distributed tech. Its usage on the municipal level is starting to happen- and its widespread application is inevitable. Transparent, anonymous and verifiable voting can change the game completely.We build a social network. It might seem too ambitious but this is just the right moment to do it. Privacy preserving, tokenized social network can be a huge leap forward for social interaction. We know how to do it, and you’ll see a prototype this summer.We’re launching Vostok network, our WEB3.0 solution for enterprise. Any implementation of blockchain tech in enterprise is WEB3.0 by default, since only a combination of different technologies, on a decentralized footing, can make sense in a corporate environment. Without it blockchain is just a weird database.We don’t solely do blockchain tech any longer; it is just a part of a bigger picture. We’re becoming the first company that focuses exclusively on monetizable WEB3.0 applications. We want to become one of the first Googles or Facebooks of the future Internet. Godspeed to us, decentralize or die!Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditOriginally published at blog.wavesplatform.com on March 12, 2019.

Application of Waves Smart ...

Blockchain is often associated solely with cryptocurrencies, but application areas for DLT are far broader. One of the most promising directions for blockchain application is smart contracts: code that is executed automatically and that doesn’t require trust between the parties who agree it.RIDE: a smart contract languageWaves has developed a special language for smart contracts, RIDE. Complete documentation is available here.A RIDE-based contract is a predicate and returns either “true” or “false”. Respectively, a transaction is either added to the blockchain or rejected. A smart contract fully guarantees the execution of conditions set out in it. At this point, the option of generating transactions from a RIDE contract is not available.Currently, Waves offers two types of smart contracts, smart accounts and smart assets. A smart account is a user’s regular account, for which a script can be set that controls all transactions. A Smart Account’s script could look, for instance, like this:match tx {case t: TransferTransaction | MassTransferTransaction => falsecase _ => true}tx is a processed transaction that we allow, using the pattern matching tool, unless it is a TransferTransaction. In RIDE, pattern matching is used for checking the type of transaction. All existing [transaction types] (https://docs.wavesplatform.com/en/technical-details/transactions-structure.html) can be processed in a Smart Account’s script.A script can also use variables, “if-then-else” statements and other methods of proper verification of conditions. To facilitate contracts’ provable termination and complexity (value) that can be predicted prior to the contract’s execution, RIDE doesn’t have cycles or jump operators.Among Waves accounts’ other features is the state. An indefinite number of pairs (key, value) can be added to an account’s state using DataTransactions. Subsequently, that information can be processed either over REST API, or directly in the smart contract.Every transaction can contain an array of proofs, in which a participant’s signature, a transaction ID, etc, might be entered.Using RIDE in IDE https://ide.wavesplatform.com/ enables display of a smart contract’s compiled view (as long as it can be compiled), creation of new accounts and setting scripts for them, as well as sending transactions from the command prompt.For a full cycle that includes creating an account, adding a smart contract to it and sending a transaction, a library for REST API can be used (such as C#, C, Java, JavaScript, Python, Rust or Elixir). To start using IDE, just hit the NEW button.Smart contracts’ possible applications range from banning transactions to selected addresses (blacklisting) to creating complex dApps.Now we’ll consider several specific examples of smart contract application in business, such as auctions, insurance and customer loyalty programs.AuctionsTransparency is one of the conditions necessary for running a successful auction: participants have to be sure that bid manipulation is impossible. This can be achieved thanks to a blockchain on which immutable data for all bids and the times when they were made is available to all participants.On Waves’ blockchain, bids can be recorded in the auction’s account state using DataTransactions.In addition, the auction’s start and end times can be set using block numbers, as Waves’ block generation frequency is roughly 60 seconds.1. English (ascending price) auctionIn an English auction, buyers place bids, competing with each other to set the highest price. Every higher bid displaces an earlier bid. If no competing bidder challenges the current bid within a given time frame, the bidder who placed it becomes the winner.In a variation of this, the seller sets a minimum price for an item. If no buyer places a higher bid than this minimum price, the item remains unsold.In this example, we show a smart account specifically created for an auction. The auction’s time frame equals 3,000 blocks and the initial price equals 0.001 WAVES. A buyer can place a bid by sending a DataTransaction with the key “price” and the value of their bid.The price of any new bid has to be higher than the current price, and the bidder has to have at least [new price + fee] tokens in their balance. The bidder’s address is added to the “sender” field in a DataTransaction and the current height of the block has to be within the auction’s time frame.If a buyer places the highest bid, they pay for the item with an ExchangeTransaction specifying the price and asset pair.let startHeight = 384120let finishHeight = startHeight + 3000let startPrice = 100000#extracting the sender’s address from the transactionlet this = extract(tx.sender)let token = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'match tx {case d : DataTransaction =>#checking if the price is defined in the statelet currentPrice = if isDefined(getInteger(this, "price"))#extracting the price from the statethen extract(getInteger(this, "price"))else startPrice#extracting the price from the transactionlet newPrice = extract(getInteger(d.data, "price"))let priceIsBigger = newPrice > currentPricelet fee = 700000let hasMoney = wavesBalance(tx.sender) + fee >= newPrice#making sure there are two fields in the current transaction and the sender is the same as the same as stated in the transactionlet correctFields = size(d.data) == 2 &&d.sender == addressFromString(extract(getString(d.data,"sender")))startHeight <= height && height <= finishHeight && priceIsBigger && hasMoney && correctFieldscase e : ExchangeTransaction =>let senderIsWinner = e.sender == addressFromString(extract(getString(this, "sender"))) #making sure that the item is exchanged by the actual winnerlet correctAssetPair = e.sellOrder.assetPair.amountAsset == token && ! isDefined(e.sellOrder.assetPair.priceAsset)let correctAmount = e.amount == 1let correctPrice = e.price == extract(getInteger(this, "price"))height > finishHeight && senderIsWinner && correctAssetPair && correctAmount && correctPricecase _ => false}2. Dutch (descending-price) auctionIn a Dutch auction, an item is initially offered at a price exceeding the amount the buyer expects to pay. Then the price is gradually lowered until a bidder accepts the current price.In this example, we use the same tools as in the previous one, also adding a delta for a step price. The account’s script checks if a participant has actually placed the first bid for the current price. Otherwise, the blockchain doesn’t accept the DataTransaction.let startHeight = 384120let finishHeight = startHeight + 3000let startPrice = 100000000let delta = 100#extracting the sender’s address from the transactionlet this = extract(tx.sender)let token = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'match tx {case d : DataTransaction =>let currentPrice = startPrice - delta * (height - startHeight)#extracting from the received DataTransaction the “price” fieldlet newPrice = extract(getInteger(d.data, "price"))#making sure that there is no “sender” field in the current account’s statelet noBetsBefore = !isDefined(getInteger(this, "sender"))let fee = 700000let hasMoney = wavesBalance(tx.sender) + fee >= newPrice#making sure there are two fields in the current transactionlet correctFields = size(d.data) == 2 && newPrice == currentPrice && d.sender == addressFromString(extract(getString(d.data, "sender")))startHeight <= height && height <= finishHeight && noBetsBefore && hasMoney && correctFieldscase e : ExchangeTransaction =>#making sure that the current transaction’s sender is indicated in the account’s state by the “sender” keylet senderIsWinner = e.sender == addressFromString(extract(getString(this, "sender")))#making sure that the аmount asset is stated correctly and the price asset is waveslet correctAssetPair = e.sellOrder.assetPair.amountAsset == token && ! isDefined(e.sellOrder.assetPair.priceAsset)let correctAmount = e.amount == 1let correctPrice = e.price == extract(getInteger(this, "price"))height > finishHeight && senderIsWinner && correctAssetPair && correctAmount && correctPricecase _ => false}3. All-pay auctionAn all-pay auction is an auction in which all bidders pay, regardless of who wins the item. Every new bidder has to pay their bid, and the highest bidder wins the item, as in a conventional auction.In our example, every participant places a bid by sending a DataTransaction with (key, value)* = (“winner”, address),(“price”, price). A bidder’s Data Transaction only gets approved if a TransferTransaction signed by them already exists and the bid is higher than the earlier bids. The auction runs until endHeight is reached.let startHeight = 1000let endHeight = 2000let this = extract(tx.sender)let token = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'match tx {case d: DataTransaction =>#extracting the field “price” from the received transactionlet newPrice = extract(getInteger(d.data, "price"))#extracting the account’s public key from the transaction’s proofslet pk = d.proofs[1]let address = addressFromPublicKey(pk)#extracting proofTx from the proofs of the received DataTransactionlet proofTx = extract(transactionById(d.proofs[2]))height > startHeight && height < endHeight&& size(d.data) == 2#making sure the winner, extracted from the current transaction is the same as the address extracted from the proofs&& extract(getString(d.data, "winner")) == toBase58String(address.bytes)&& newPrice > extract(getInteger(this, "price"))#verifying that the transaction was signed&& sigVerify(d.bodyBytes, d.proofs[0], d.proofs[1])#checking the correctness of the transaction, stated in the proofs&& match proofTx {case tr : TransferTransaction =>tr.sender == address &&tr.amount == newPricecase _ => false}case t: TransferTransaction =>sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)|| (height > endHeight&& extract(getString(this, "winner")) == toBase58String((addressFromRecipient(t.recipient)).bytes)&& t.assetId == token&& t.amount == 1)case _ => sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)}Insurance / CrowdfundingLet’s consider a situation where we need to protect users’ assets from financial loss. For instance, a user may want to ensure that they will be able to recover the entire amount paid for tokens in case of the token’s devaluation, and are prepared to pay a reasonable insurance premium.For that purpose, “insurance tokens” will be issued. A script to the insured’s account is applied, allowing only ExchangeTransactions that meet certain conditions.To prevent double spending, the insured user initially needs to send a DataTransaction to the insurer’s account with (key, value) = (purchaseTransactionId, sellOrderId) and prohibit sending DataTransactions with the same keys.Consequently, the user’s proofs have to contain the ID of the transaction for the purchase of the insurance token. The asset pair has to be the same as in the purchase transaction. The price has to be equal to the token purchase price, with the insurance premium price deducted.It is implied that the insurer’s account will later buy the insurance tokens from the user at a price no lower than the purchase price. The insurer’s account will create an ExchangeTransaction, and the insured user will sign an order (if the transaction is correct). The insurer’s account will sign the second order and the entire transaction, and send it to the blockchain.If no purchase takes place, the user can create an ExchangeTransaction under conditions set in the script and send the transaction to the blockchain. That way, the user will recover the funds spent for the purchase of insured tokens.let insuranceToken = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'#extracting the sender’s address from the transactionlet this = extract(tx.sender)let freezePeriod = 150000let insurancePrice = 10000match tx {#verifying that if a DataTransaction has arrived, it has just one field and there is no second key in the statecase d : DataTransaction => size(d.data) == 1 && !isDefined(getBinary(this, d.data[0].key))case e : ExchangeTransaction =>#if a transaction doesn’t have the seventh proof, we’re verifying the signatureif !isDefined(e.proofs[7]) thensigVerify(e.bodyBytes, e.proofs[0], e.senderPublicKey)else#if the transaction has the seventh proof, we’re extracting from it the transaction and discovering its heightlet purchaseTx = transactionById(e.proofs[7])let purchaseTxHeight = extract(transactionHeightById(e.proofs[7]))#processing the transaction from the proofmatch purchaseTx {case purchase : ExchangeTransaction =>let correctSender = purchase.sender == e.sellOrder.senderlet correctAssetPair = e.sellOrder.assetPair.amountAsset == insuranceToken &&purchase.sellOrder.assetPair.amountAsset == insuranceToken &&e.sellOrder.assetPair.priceAsset == purchase.sellOrder.assetPair.priceAssetlet correctPrice = e.price == purchase.price - insurancePrice && e.amount == purchase.amountlet correctHeight = height > purchaseTxHeight + freezePeriod#verifying that the current transaction’s ID is stated correctly in the proof transactionlet correctProof = extract(getBinary(this, toBase58String(purchase.id))) == e.sellOrder.idcorrectSender && correctAssetPair && correctPrice && correctHeight && correctProofcase _ => false}case _ => sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)}The insurance token can be made a smart asset — for example, to prohibit its transfer to third parties.This scheme can also be used for crowdfunding tokens, which are to be returned to the holders if a required sum of money has not been collected.TaxationSmart contracts are also applicable in a situation when every transaction for several types of asset needs to be taxed. This can be implemented with a new asset, with added sponsorship for smart asset transactions:We issue FeeCoin, which will be sent to users at a fixed price: 0.01 WAVES = 0.001 FeeCoin.We set sponsorship for FeeCoin and specify the exchange rate: 0.001 WAVES = 0.001 FeeCoin.We set the following script for the smart asset:let feeAssetId = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf’let taxDivisor = 10match tx {case t: TransferTransaction =>t.feeAssetId == feeAssetId && t.fee == t.amount / taxDivisorcase e: ExchangeTransaction | MassTransferTransaction => falsecase _ => true}Now, every time someone transfers N smart assets, they will send you N / taxDivisor FeeCoins (which could be bought from you at 10 *N / taxDivisor WAVES) and will send N / taxDivisor WAVES to the miner. As a result, you will collect a profit (tax) of 9 *N / taxDivisor WAVES.Taxation could also be implemented with a smart asset script and MassTransferTransaction:let taxDivisor = 10match tx {case t : MassTransferTransaction =>let twoTransfers = size(t.transfers) == 2let issuerIsRecipient = t.transfers[0].recipient == addressFromString("3MgkTXzD72BTfYpd9UW42wdqTVg8HqnXEfc")let taxesPaid = t.transfers[0].amount >= t.transfers[1].amount / taxDivisortwoTransfers && issuerIsRecipient && taxesPaidcase _ => false}Cashback and loyalty schemesCashback is a type of a customer loyalty scheme in which a percentage of funds spent on goods or services is paid back to the customer.In the implementation of this case with a smart account, we need to check proofs in the same way as in the insurance use case. To prevent double spending, before collecting a cashback, a user has to send a DataTransaction with (key, value) = (purchaseTransactionId, cashbackTransactionId).Also, we need to prohibit setting DataTransactions with the same keys. cashbackDivisor is a reverse number for a cashback share. If the cashback share is 0.1, cashbackDivisor will be 1 / 0.1 = 10.let cashbackToken = base58'8jfD2JBLe23XtCCSQoTx5eAW5QCU6Mbxi3r78aNQLcNf'#extracting the sender’s address from the transactionlet this = extract(tx.sender)let cashbackDivisor = 10match tx {#verifying that if a DataTransaction has arrived, it has just one field and that key is not yet in the statecase d : DataTransaction => size(d.data) == 1 && !isDefined(getBinary(this, d.data[0].key))case e : TransferTransaction =>#if the transaction has the seventh proof, we’re verifying the signatureif !isDefined(e.proofs[7]) thensigVerify(e.bodyBytes, e.proofs[0], e.senderPublicKey)else#if the transaction has the seventh proof, we’re extracting the transaction from it and finding out its heightlet purchaseTx = transactionById(e.proofs[7])let purchaseTxHeight = extract(transactionHeightById(e.proofs[7]))#processing the transaction from the proofmatch purchaseTx {case purchase : TransferTransaction =>let correctSender = purchase.sender == e.senderlet correctAsset = e.assetId == cashbackTokenlet correctPrice = e.amount == purchase.amount / cashbackDivisor#verifying that the current transaction’s ID is correctly stated in the proof transactionlet correctProof = extract(getBinary(this, toBase58String(purchase.id))) == e.idcorrectSender && correctAsset && correctPrice && correctProofcase _ => false}case _ => sigVerify(tx.bodyBytes, tx.proofs[0], tx.senderPublicKey)}Atomic swapAn atomic swap enables users to swap assets without using exchanges. In an atomic swap, approval from both participants of the transaction is required within a specified time frame.If at least one of the participants fails to approve the transaction within the specified time frame, the transaction is cancelled and funds are not exchanged.In our example, we use a smart account script:let Bob = Address(base58'3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8')let Alice = Address(base58'3PNX6XwMeEXaaP1rf5MCk8weYeF7z2vJZBg')let beforeHeight = 100000let secret = base58'BN6RTYGWcwektQfSFzH8raYo9awaLgQ7pLyWLQY4S4F5'match tx {case t: TransferTransaction =>let txToBob = t.recipient == Bob && sha256(t.proofs[0]) == secret && 20 + beforeHeight >= heightlet backToAliceAfterHeight = height >= 21 + beforeHeight && t.recipient == AlicetxToBob || backToAliceAfterHeightcase _ => false}In our next article, we’ll look at the application of smart accounts for financial tools, such as options, futures and bills of exchange.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditApplication of Waves Smart Accounts: from Auctions to Customer Loyalty Schemes was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves Launches Waves Rewar ...

We are launching Waves Reward Token, a smart asset that the Waves community will be able to use to reward ambassadors.To incentivise Waves ambassadors and facilitate feedback from the community for our Ambassadors program, we are launching Waves Reward Token (WRT), which will also be used to demonstrate the potential of smart assets.Next week, all holders of Waves Community Token who hold at least 10 WCT in their wallets will receive 100 WRT. They will subsequently be able to send WRT to Waves ambassadors as a reward for their activities.The total number of issued WRT will be twice the supply of WCT held by the community. Waves will retain 50% of the total stake so that it can also reward ambassadors.Thanks to the smart asset’s script, only ambassadors will be able to sell WRT, which Waves will buy back.The smart asset will operate as follows:WRT can only be sent to whitelisted addresses (those of ambassadors)The token cannot be burntIt cannot be traded on DEX; only whitelisted addresses can sell itNew logic can be added to the scriptAs this programme is experimental, the smart asset will be renewable, available for renewal on a quarterly basis. If we see substantial interest, we may want to expand the programme to incentivise and reward the community’s most active members.By introducing WRT, we would like to encourage the Waves community to keep track of ambassadors’ activities, expressing opinions and rewarding them, if they deserve it.We expect the ambassadors to actively share information about this programme among the community and call on community members to participate. In turn, we will help our ambassadors share information about their activities within the Waves and crypto worlds!If you want to take part in this new initiative, make sure that you have at least 10 WCT in your wallet!Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves Launches Waves Reward Token was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Outstanding New Dice Game ...

We are thrilled to introduce a new Waves blockchain-powered game!The folks at Tradisys have delivered once again, with a fantastic new dice game. The smart-contract powered game is — hands down — better than anything else that currently exists in the blockchain space in terms of design and UX, technology and transparency.All you’ll need is a Waves wallet and Waves Keeper installed for your browser. The game is fully decentralised and you can actually check what’s going on behind the scenes as you play, meaning it’s absolutely transparent in real time.Start by selecting up to five numbers from your dice. The more faces you add, the higher your chances of winning — but your prize WAVES will be proportionally lower. You can stake 2, 5, 10, 15 or 20 WAVES on each game.When you hit Play, Waves Keeper will pop up and confirm your numbers, and the amount (including the transaction fees). After just a few seconds, you’ll find out what number you rolled and whether you won! If you did, the WAVES will appear in your account after 1 block or around 1 minute.There’s a built-in rating system and if you turn out to be lucky then you’ll end up on the leaderboard, as well as picking up some prize WAVES. If you’re not so lucky, you’ll be pleased to hear that all the WAVES collected from the game will be sent to the the Charity fund.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditOutstanding New Dice Game Added to Waves Ecosystem was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves statement on Bitcoin ...

Waves Statement on Bitcoin Cash Network SplitWe will shortly be opening gateways for the fork coins BCH and BSV.As you likely know, some time ago the Bitcoin Cash network hardforked and the ecosystem has now divided into two separate blockchains, Bitcoin Cash (BCH), and Bitcoin Cash Satoshi Vision (BSV).The two networks are now distinct, and BSV has subsequently established an independent trading history and community, while BCH (also known as Bitcoin Cash ABC or BCHABC) inherits and continues the trading history of the original coin. Since it is clear that both coins will have a future and value, we will be reflecting this in our treatment of Bitcoin Cash in the Waves Client.Balances snapshotWe will pause trading of BCH to take a snapshot of balances, after which BCH holders will receive an equal amount of BSV. Trading with then will be relaunched with the new asset. Two gateways, BCH and BSV, will be enabled, so that users can deposit and withdraw coins, and trade them on Waves DEX.At the time of writing, we are planning to hold the snapshot for BCH balances on Friday 22 February at 00:00 Pacific Time.Gateways will be enabled on Thursday 28 February at 23:00 Pacific Time.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves statement on Bitcoin Cash network split was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves dApps Roadmap for 2019

RIDE is Waves’ native smart contracts programming language. After a successful launch of basic functionality, we are now going to focusing on overhauling RIDE to extend it — making it more powerful, easier to use and enabling develops to access new blockchain functionality.RIDE PrinciplesRIDE is a blockchain scripting language, which enables ‘smart’ blockchain transactions. The execution result is predicated on certain logic, realised using RIDE scripts and deployed on the blockchain. The goal of RIDE’s architecture is to create a native on-chain computation layer which is as close to the general blockchain architecture (full data synchronisation) as possible.We strongly believe that Turing-completeness should not be essential for on-chain blockchain computations. The RIDE language itself is explicitly non-Turing complete. However, in the context of its execution environment (i.e the blockchain) it does allow for essentially Turing-complete computations that are ‘spread over’ more than one transaction in consecutive blocks.RIDE language supports the concept of fixed fees: that is, the same computational costs for the execution of any script. This results in the explicit limitation of scripts’ complexity and the lack of any gas-like requirements, as are found in Ethereum.Current Waves and RIDE architecturePrior to the introduction of RIDE, Waves’ core entities were Accounts, Tokens and Data.Accounts could hold TokensAccounts could have Data associated with themThe initial introduction of RIDE extended the idea of signing transactions: the default account predicate required a valid signature for any outgoing transaction for the given account’s public key. Smart Accounts allowed that to be changed to a custom condition: signatures, hashes, timelocks, arbitrary account data, and so on. To describe the Smart Account predicate, a RIDE function annotated with @Verifier and returning a Boolean value needs to be deployed to the blockchain.Just as Smart Accounts extend the ‘Valid signature requirement’ to a ‘Custom requirement’ for outgoing transactions, Smart Tokens extend the idea of “Any operation with a token is allowed, given that the invariants are satisfied” to ‘Any operation with a token is allowed, given the invariants are satisfied AND a token predicate condition (which is, again, based on signatures, hashes, timelocks, arbitrary account data, etc) is satisfied.’ To describe a Smart Token predicate, a RIDE expression returning a Boolean value needs to be deployed to the blockchain.So far the programmable capabilities of the Waves blockchain have remained passive, simply being predicates over user-initiated transactions.Introducing RIDE for dAppsTo improve on this shortcoming, RIDE for dApps is being introduced. This grants an account a way to assign a programmable function to itself. Each @Callable function is able toReceive paymentsChange the account’s stateSend WAVES and tokens from the accountTo initiate the call, a new InvokeScriptTranscation needs to be put on the blockchain. The sender pays fees to the miner for the invocation. The sender can optionally attach payment in WAVES or tokens, and upon invocation the contract state can be changed and the contract can make multiple payments.The current mechanics of authorisation scripts will be preserved under the @Verifier function of the account. You can think of it as an ‘admin’ function of the contract for owner(s). By default, a contract’s attributes (the contract itself, contract data and contract tokens) are controlled by the account’s private key. This can be changed to multisig and so on. If @Verifier is always false, the contract is sealed.@Callable(invocation)func fomo() = { WriteSet(…)}@Callable(invocation)func withdraw(amt: Int) = { TransferSet(…)}@Verifier(tx)func verify() = { false}Default functionAs an experiment, we are considering the introduction of yet another annotation: the @Default function for a contract. The idea here is to specify a callback function for receiving WAVES/tokens. For the system to be explicitly non-recursive, the @Default function can only change contract state.@Default(incomingTransfer)func onReceive() = { WriteSet(...)}RIDE improvementsFurther feedback we received from developers and hackathons relates to the lack of clarity and current immaturity of the API of the RIDE language. We address this in the upcoming release.First, we introduce the ability to write non-recursive functions.func maxPositive(a: Int, b: Int) = { func max(x:Int, y:Int) = { if (x>y) then x else y } max(max(a,b), 0)}The next issue we address is related to the syntax of reading values blockchain state/oracles. Since the value by key in an oracle/contract may not be present, the return type for getInteger, getBoolean, … is UNION(Integer/Unit), UNION(Boolean/Unit). To get the actual value the following syntax had to be used:let address = ...let value = extract(getInteger(address, “someKey”))To improve on that, another way of invoking functions is introduced (the left and right invocations are the same and only represent the syntax change):The current complexity for a script is set to 2,000, which is enough to check up to 19 signatures and any smaller subset of operations, but for dApps this is not enough. We will extend the maximum complexity for function invocation to 10k.The standard library will be improved in the upcoming release. The current set of functions and primitives was introduced as the minimum necessary for authorization scripts. With decentralised applications, this needs to be extended to support a wider range of common functionality like binary conversions, richer string operations, and so on.As part of extending the RIDE standard library, more functionality to query blockchain state will be added to RIDE. Detailed information on assets, balances, last blocks and miners will be exposed through a revamped blockchain API.Keys in account/contract storage are currently Strings. This is a useful limitation for DataTransactions as it provides readability and ease of use via REST API, but might be inefficient for dApp Storage, since it will require back-and-forth conversion if keys are designed to be bytevectors. We’ll provide a capability for storing values by bytevector keys.IDE and TestingCurrently, hints in IDE are limited to global functions and transaction types and fields. This is not enough for a smooth coding experience, so we will improve on that.The ability to test any code, especially smart contracts, is essential. As important as running manual tests on testnet is, a form of sandboxed unit testing preserving all the semantics can speed up development and debugging, and provide better quality assurance. To help with that, a test framework running actual node code(without the rest of the node) will be introduced.Here is a small example of how this framework will look like:val contract = Address(“seed”)val caller = Address(“seed 2”)val scriptText = “ @Callable(i) func foo(arg: Int) = { WriteSet(DataEntry(“arg”, arg)) }”transfer(wallet, contract, 1.waves)setScript(contract, scriptText)transfer(wallet, caller, 1.waves)contractInvocation(caller, contract, “foo”, List(42)))getInteger(contract, “arg”) shouldBe 42RoadmapJoin Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves dApps Roadmap for 2019 was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Microsoft Azure Cloud Feat ...

Waves steps up integration with Microsoft Azure, making its Smart Asset and Smart Account functionality available to developers on the cloud platform.Waves’ smart accounts and smart assets are now available to developers on Azure Marketplace in a special extension for Visual Studio Code, which simplifies the process of creating and operating smart contracts.Two new virtual machine templates in Azure can be used for setting up new options on a public or private blockchain.‘Unlike other similar solutions, non-Turing complete smart contracts from Waves offer increased security and protection from vulnerabilities due to the option of restricting functionality to avoid undesirable use’, comments Sasha Ivanov, Founder and CEO of Waves Platform.‘A special extension for Microsoft Visual Studio Code editor will simplify the process of writing smart contracts for developers, allowing them to work in complete integration with Microsoft Azure cloud,’ he continues. ‘I am confident that users will hugely appreciate the variety of opportunities and possibilities this opens up for them!’‘We believe that supporting open-source platforms and facilitating the widespread availability of contemporary technological tools for the developer community is very important,’ says Konstantin Goldstein, Microsoft Russia’s principal technical evangelist.‘Waves is one of world’s leading blockchain platforms, which contributes substantially to the development of an ecosystem for global decentralised solutions, and we are glad to support the company in its development,’ he adds.Waves Platform has been deployed in Azure cloud since 2017.The functionality of Waves’ smart accounts and smart assets can be applied in a variety of use cases, including supply chain management, verification of documentation, organization of internal transactions, filing accounting reports and game development.Read more about Waves Smart Accounts and Smart Assets.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditMicrosoft Azure Cloud Features Waves’ Smart Assets and Smart Accounts was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

New Smart Contract-Powered ...

We are pleased to introduce a new game based on Waves smart contracts. It’s very simple, but only the most patient player will win all the money…The game creators from Tradisys have been inspired by cult movie The Fifth Element and have created a game on the theme of the film. The game is completely decentralised: there are no sources of external influence and it is controlled solely by the rules of a smart contract. It uses Waves Keeper to ensure the process is safe and secure: because your SEED is never exposed to the web, you’re not trusting any third party with your funds.To take part, you need to transfer 1.1 WAVES to the smart contract of the game. Every time a participant enters the game, the countdown is reset and records a DataTransaction with the address of the last player’s wallet on the blockchain.To win, the counter must reach zero — with the last address to enter becoming the winner. If someone else sends a transaction and updates the counter, the previous player is eliminated. The wait duration for the counter is 60 blocks, which is approximately 60 minutes, though can be shorter or longer.To play you need:1. Desktop operating system (Windows, MacOs, Linux).2. The latest version of Google Chrome or Firefox.3. Waves Keeper installed (Chrome, FireFox).4. A minimum balance of 1.2 WAVES.Game instructions:1. Click the “Buy ticket” button.2. In the pop-up window, sign 2 transactions using Waves Keeper:- TransferTransaction (1.1 WAVES and 0.1 Commission)Then click NEXT- DataTransaction3. If the first two steps are carried out correctly, your payment will be recorded by the contract, and the counter at the top of the screen will be updated.4. The last player to buy a ticket before the countdown hits zero will receive the entire amount held by the smart contract.5. You can play at any time (if you’re not the last player to make a transaction, there’s no point in waiting).6. There is no limit to the number of entries a player can make.This is how the interface looks:The game is available here: multi-pass.clubFor technical information, developers can contact the creators of the game here: https://t.me/tradisys_globalIf you have questions about the game , you can ask them in the official Waves telegram chat — use the @tradisys tag.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditNew Smart Contract-Powered Game Launches on Waves was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Solving Challenges with Sm ...

In late 2018, Waves Platform released Smart Assets on MainNet and launched Tokenomica, a fully compliant exchange for digital assets. This article, centered on use cases for Smart Assets, comes as the first in a series focused on how Waves solutions facilitate building the financial system of the future.Cryptocurrency TradingOver the last couple of years, regulated crypto exchanges have faced challenges related to compliance with requirements imposed by regulators. Specifically, those requirements include user identification and quality assurance of assets admitted to trading.Tokenomica offers a solution to these challenges based on technologies already proven successful on Waves DEX, and centered on Smart Accounts and Smart Assets.Smart Account is an account with an attached transaction script, which allows to validate every transaction before confirming it. Smart Account allows restricting any outgoing transaction based on multi-signatures and other supplied data.In Tokenomica, Smart Accounts will be used to allow outgoing transactions only to users that were previously identified and approved, or so called “whitelisted” users, in order to comply with relevant regulatory requirements.In addition, for compliance or security reasons, transactions could require two signatures: one from the user, and another one from Tokenomica.Smart Accounts will allow Tokenomica to make sure that any transaction made on the platform is only possible between whitelisted users.But what about the quality of traded assets? Here is where Smart Assets come into play.Smart Assets are unique tokens (meaning that they contain a unique set of rules provided in the script) that can be purchased, sold or exchanged as defined by the script, which validates every transaction within that asset.In Tokenomica, Smart Assets will be used to restrict trading to pre-approved pairs of assets. Pairs will be formed by assets compliant with relevant regulations, based on applicable rules and guidelines provided by the regulators.STOsAnother promising area for implementation of Smart Assets is Security Token Offerings (STOs). We define security tokens as financial instruments subject to securities markets regulation that are issued and traded with the use of blockchain.Smart Assets allow issuers to design their security tokens in a customized way, creating a fully compliant asset with attractive features for the investors.These are benefits that security tokens can bring to financial markets:Reduction of listing fees for issuers who will be able to access liquidity of secondary markets through security tokens trading platforms instead of going through burdensome and costly process of listing on traditional exchanges;Automated corporate actions, redemptions and periodical payments processed on the blockchain;Immediate execution of deals at any time — something that is not available on financial markets, bound by working hours of exchanges, custodians, clearing houses and other financial intermediaries;Access to new types of investors familiar with the industry, who will be willing to invest in security tokens to support technology based projects.What elements of a security token can be designed with the use of Smart Assets?Transferability of instruments and record keepingPre-emption rights: there are cases when a company’s shareholders are restricted from selling their shares to anyone except other shareholders. This restriction can be implemented in Smart Assets’ script, allowing the transfer of security tokens only between their holders.Qualification of investors: in some cases securities can be offered only to qualified or accredited investors. Breaching this requirement can lead to negative implications and fines for the issuers. Smart Assets’ script can incorporate a restriction allowing their transfer only to investors classified by the issuer as qualified or accredited.Record keeping: the issuer may be required to keep record of all its shareholders. Issuing a share in form of a Smart Asset creates an electronic database of shareholders on the blockchain, which is updated in real time taking into account every transaction with tokens between the investors.Convertible instrumentsIssuers can establish certain conditions for converting financial instruments into another type of security. For example, if a predetermined date is reached, an equity warrant can be converted into a share in the company. Such conditions can be implemented into Smart Assets and become automatically enforceable by the script, significantly reducing the burden for the administration of the conversion process.Payments and redemptionA process for periodical payments could be made substantially simpler and cheaper thanks to cutting intermediaries. If securities are issued on the blockchain, payments are made to token holders’ addresses, known to the issuers, which reduces the costs for payment administration.Also, with Smart Assets, a new payment option can be introduced allowing to calculate periodical payments based on a certain set of requirements. For example, the amount of dividends paid to a specific investor could increase depending on the amount of time for which the token is held by such an investor (so called “loyalty dividends”).In addition to periodical payments, securities have a redemption price, which can be fixed or calculated upon certain conditions. Those conditions can be implemented in Smart Assets’ script, making the redemption process fully automated for the issuers.Workable Solution for Financial MarketsSmart Assets represent a perfect solution for business models that require implementation of restrictions, required for compliance or other reasons.Just about any product to be offered in the financial services industry without breaching applicable laws and regulations, specifically when regulated cryptocurrency exchange or security token offerings are involved, is set to face restrictions.However, the good news is that Tokenomica offers a workable solution for regulatory challenges in the financial markets.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditSolving Challenges with Smart Assets was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves to Take Part in Bloc ...

Next week, Waves will participate in Blockchain Gamer Connects, the first event dedicated exclusively to blockchain games and held simultaneously with Pocketgamer Connects and PC Connects on January 21–22.Waves’ Inal Kardanov will make a presentation called “Fueling the Revolution,” focused on disruption of existing relations between developer and player, which blockchain is bringing to the games sector.Currently, players own nothing in the game. They could spend money on buying an item or time on growing a character, but, in the end, they can’t sell or swap those.However, tokenization has the potential to revolutionize in-game economies, facilitating ownership of items by players. Legitimate trade of items for an in-game currency could also help to crack down on digital games’ black economy.Overall, Blockchain Gamer Connects will be centered on exploring blockchain technology’s potential to introduce inevitable changes into the games industry.Thanks to blockchain, a whole new category of dApps, enabling secondary markets for in-game digital assets and new models for rewarding players has arrived, but there are numerous other applications of the technology in the gaming sector, limited only by developers’ imagination.Inal’s presentation is to be held on January 21, at 12:20pm. In addition, Waves will host a VIP reception.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves to Take Part in Blockchain Gamer Connects was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waves Christmas Game Prove ...

Our Christmas game turned out to be a huge success. It entertained many over the holidays and the funds collected will benefit children from a hospice in Moscow.From 24 December to 8 January, hundreds of people had fun playing Waves’ Christmas game, developed in collaboration with Tradisys.In playing the game, users were not only able to try out Waves’ smart contracts, but also benefit a good cause, bringing joy to children at local hospice.Waves Smart Contracts pass the testThe Christmas game — Waves’ first MainNet gaming project — formed a major test for the application of Waves smart contracts and Waves Keeper within the gaming industry.Each game session launched by a player generated a smart contract, decentralising backend operations and ensuring that funds went exactly where they were intended.Now that the game is over, we can say that Waves’ smart contracts successfully passed the test with flying colours, proving their reliability and efficiency!Children to benefitOver the course of the game, players found more than 500 WAVES under the Xmas Tree. In total, over 1,100 games were played.Gamers donated 890 WAVES, to which we added 1,110 WAVES, making a total of 2,000 WAVES. These funds will be donated to the Children’s hospice.We at Waves are strongly convinced that blockchain can truly contribute to making this world a better place. And the success of the Christmas game comes as another testimony to the technology’s significant real-world adoption potential.To give developers a detailed understanding of how Waves smart contracts’ were used in the Christmas game, we will soon publish a more in-depth technical review.Join Waves CommunityRead Waves News channelFollow Waves TwitterSubscribe to Waves SubredditWaves Christmas Game Proves a Success! was originally published in Waves Platform on Medium, where people are continuing the conversation by highlighting and responding to this story.