Smart Assets Proposal

Core Development
22

I am saying you can’t do anything now too :slight_smile: except using a filter that can make them invisible. Burning like sending the spam tokens to one account that you don’t know the seed. :slight_smile: So the spammer can keep send the tokens that you burned. I didn’t check the smart assets fully but there could be a feature for accounts to reject payment for a specific token.
or blacklist issiuer or whitelist issiuer or white and blacklist tokens etc… There could be much more… Actually don’t have much time to check smart contracts and learn syntax so this is just the potential that can be add easily to avoid from spammer. Those are the way to block spammers from decentralize way. But a filter on desktop wallet like I mentioned can solve it easily. But I guess they don’t want to make it from centralized way.

23

BTW, can we issue a token that can be reissue by different accounts who is attached with multi-sign script.
@dkiselev

24

@karmenali, sorry, but you’re wrong almost in everything you say, read docs first.

As for filters. Technically, API calls still delivers full information about account and all assets, if you do not see spam, it does not dissaper. It is present in every call. For example, try to check assets on these accounts:

Even if you filter it on a post processing, measure the time you need to load the page.

25

You really didn’t get what I am saying. That’s true explorer get full information about accounts. But they can change it easily with a filter to show only basic tokens. E.g waves explorer shows only 100 tx , wavesdex shows 300tx and exchange txs in different tab. That’s all up to developers. If waves team don’t want to show X token on your account they can do it easily in both explorer , desktop wallet, telegram bot etc… So, smart assets can’t change your api call to make token visible in every api call :slight_smile: If there is such a power like that, waves should be 10k usd :slight_smile:
if account == ‘valid’:
print(wavesBalance, wctBalance, …) #what do you want to display on screen

26

Now you telling me, what if there was a server side mechanism to filter valid tokens it wouldn’t be the problem. Please see my first post, i did started with that.

For now, all filtering takes place on a client side.

So i completly support smart assets if i can filter them on the blockchain, not on a client.

But such a paired with smart assets but limiting mechanism has not yet been provided.

27

Here is your argument. And I support that burning tokens can’t be a solution. If all your concern about spam tokens here some solutions;

  • Build your own filter which is easy way to do.
  • Offer to the team to create such a mechanism with SC to attache a script to your account. That script should work like that : define a whitelist tokens id. if the token id is not in whitelist burn it - don’t except payment etc…

For now you can’t filter any token on the blockchain. The issiuer sending you an input and if filled the requirements on blockchain he can send you anything that he wants. We need a new feature in smart contract to make such a mechanism to able burn or if it is possible to not except this tokens. Maybe we need to wait turing complete. But as I said you can’t act like a issiuer on blockchain if you don’t have a permission to control the account. Only can describe your own rule for your own account.
One more, we can change the all rules and make the tokens non-transferable from the beginning and build a new voting mechanism similar to DAO and if the token pass the vote step with at least %51 support, turn it transferable.

28

The issuer is able to issue an asset and add a script to their account with the following logic:

anyone can sign a ReissueTransaction for this asset and transfer the asset from the issuer’s account (the issuer’s account becomes something kinda faucet: https://testnet.wavesexplorer.com/faucet ). So the issuer can specify that these transactions can be signed by accounts from a whitelist or even anyone.

Still, the asset’s issuer has to be the sender of the ReissueTransaction, so we’re sure that all this logic is on their consent. The reissued tokens will be generated on the issuer’s account.

29

Hey. We are developing a fintech project on the waves. We are very interested in implementing a smart contract in your project. The idea is that a smart contract should act as an insurance (insurance wallet) for our clients in case we do not fulfill our obligations. Example: A client purchased a contract for 3 months from us for our tokens. After the expiration of the contract within a certain period we must return to him the amount of the contract with the bonus! If we did not do this, the Client should receive a 100% return of the tokens for the Insurance, if he insured his contract! If there is no insurance, then he gets nothing! If we paid him everything (at least his contribution), then he should not get insurance either!
The question is whether it is feasible at this stage on the platform?

30

Hi @moleg42 ,
I think you can do this:

Issue “insured tokens” (that is, you will sell two types of tokens: contract-tokens and insured-contract-tokens). The cost of insurance is included in the cost of the insured-token and is additionally specified in the wallet script.

Set a script to the wallet-account with the following logic:

allow ExchangeTtransactions that satisfy the following conditions:
1) the proofs contain the ID of the insured-token purchase transaction
2) Asset pair is the same as in the purchase transaction
3) the price is the same as in the purchase (minus the price of the insurance itself)
4) height > height after 3 months from the time of purchase (or some other condition)
other transactions have to be signed by the wallet account.

It is implied that you’re gonna buy insured-tokens from a client at a price not lower than the purchase price: you create an ExchangeTtransaction, the client signs an order (if everything suits them), you sign the second order and the whole transaction and put it in the blockchain. If you do not do this, then after a certain time the client is able to create an ExchangeTtransaction according to the rules described in the script, and put it in the blockchain - that is, the client is able to return the money for which this token was bought.

The insured-token, if desired, can be made a smart asset, for example, transferring to third parties can be prohibited.

31

To prevent double-spending you should also ask a client to send a DataTransaction beforehand to your account with (key, value) = (purchaseTransactionId, sellOrderId) and prohibit setting DataTransactions with identical keys.

32

Спасибо Дмитрий за ответ. Мне надо еще его осмыслить. Так как разработчики и пользователи не всегда говорят на одном языке.

34

Here’s a description of implemented smart assets’ features that will be included to the next release:

35

Thanks for great features! I really appreciate it.