Welcome to the discussion thread about this lecture section. Here you can feel free to discuss the topic at hand and ask questions.
@filip Good day
In the Token Creation video, you create the 10000 Dogcoin token with the bob account, then you issue him 1000 token.
My question is, who does the 10000 tokens that bob originally created belong to? because even if he created them, he still had to give himself 1000, who does the 9000 belong to?
@filip
Good Day
In the Building Listener video., What I am understanding is, With the notify of the eosio.token transfer on the pay function, anytime someone does a transfer to the inline account it fires.
So, correct me if im wrong, if my name is bob, and I want to insert my dog, I call " cleos transfer bob inline â20 DOGCOINâ âmemoooâ -p bob@active"
That notify then fires, What happens thou, if another contract is published in the inline account with a listener on the transfer?
-
The 9000 tokens donât really belong to anyone. The token is created but not minted. The 10000 number is the maximum supply, the maximum number of tokens that can ever be minted. Then we mint 1000 to bob. Then he owns them. Makes sense?
-
Your understanding is correct. I donât understand your question though.
What happens if another contract is published in the inline account with a listener on the transfer?
It depends on what contract is deployed there. Our inline action exists only in our contract, if we deploy another contract to the inline account then the functionality will be replaced with the new contract. But maybe I misunderstood you.
@filip Ok thanks for the answer in question 1, but to expound on question 2.
We have our DOGCOIN and we can insert our dog etc. Lets say we create a CATCOIN where we pay for cats and that contract also have a listener. What happens when we say âcleos transfer bob inline â20 CATCOINâ âmemoooâ -p bob@activeâ" wonât the listening we have on the dog fire? if no, why not?
Do you mean that you create a new contract, CatContract, and deploy that to the inline account? If thatâs the case then the DogContract is not deployed anymore, it has been replaced, and therefor the old inline action wonât fire. Instead, we might have another inline action in our CatContract that will fire instead.
Let me know if anything is unclear 
@filip
Greetings, I have a question. In the building listener video you created a listener that sent tokens via the eosio.token contract and when it called it triggered a void pay function, and also down in the charging video you did things like charge users for inserting dogs etc.
Hereâs the question, Lets say you have 50 Dogcoins but you never interacted with this contract before, what I am understanding is, if you want to insert your dog. You need to first âpayâ the contract, or âgive the contract moneyâ. to then be able to spend it in the contract. If I am applying this to real life, you have $50 in your pocket, but if you want to go buy ice cream you need to give the clerk about $20, before you can even go inside and pick out what ice cream you want.
Is that the way it works? or is that how you chose to handle this, because even if bob had dogcoins, he could not interact with the contract
Hi there. Yes you are correct in your analogy. This is how payable functions generally work in EOS and how most people build them. You could code it differently which eliminates that first step, but it would not be possible for all use cases and would require a lot of skills on the purchaser side. I talk about this in the lecture on improvements. Listen to that and let me know if you have any further questions.
@filip Ok thanks, But lets say, I said 11 Dogcoins to the contract, but it cost 10 to insert a dog, how do I get back my 1 dogcoin?
Ran into the below error
$ eosio-cpp -I include -abigen -o eosio.token.wasm ./src/eosio.token.cpp
Warning, empty ricardian clause file
/usr/local/Cellar/eosio.cdt/1.6.2/opt/eosio.cdt/bin/wasm-ld: error: fatal failure: contract with no actions and trying to create dispatcher
I created eosio.token account to fix this issue but still no luck
1 Like
I think I saw that error before, happened to me when I copied code and the contract was named differently than the project. I could be wrong but, make sure names match up. Hopfully Ivan lends more clarity to you
1 Like
U guessed right typo in eosio.token account. Once the name matches all good.
1 Like
You would have to build a function in the contract that sends the money back to the owner.
Thanks for helping each other
@filip So it would be like ⌠a ârefund meâ function where the individual enters how much he wants back?
Yeah, ârefundâ or âwithdrawâ. You could make both withdraw where the user enters the amount and withdrawAll where you withdraw all of it.
It would be good practice to implement this. Let me know how it goes
@filip Iâm trying to set the contract and getting a permission err⌠I didnât create a account called âeosio.code@activeâ. Is that your specific account that you created or is that a system account?
mbarsf:eosio.token perry$ cleos set contract eosio.token /Users/perry/dev/eos201/contracts/eosio.contracts/contracts/eosio.token ./eosio.token.wasm --abi eosio.token.abi -p eosio.code@active
Reading WASM from /Users/perry/dev/eos201/contracts/eosio.contracts/contracts/eosio.token/./eosio.token.wasmâŚ
Publishing contractâŚ
Error 3090003: Provided keys, permissions, and delays do not satisfy declared authorizations
Ensure that you have the related private keys inside your wallet and your wallet is unlocked.
Error Details:
transaction declares authority â${auth}â, but does not have signatures for it.
Hi. maybe I can take a look at this for you tonight, but i see you get a signature/authentication error. Can you tell me, how you got the error and what you have tried to do to fix it? 
maybe you can take a screenshot of you code?
Ivo
Resolved! I had not created the user eosio.code account. thank u It was late last night
1 Like
