If a canister is the owner of tokens in a ledger, then that canister is deleted, are these tokens lost, if an internet identity was controller over the deleted canister?
Is there a way to say this internet identity was the controller of this canister and therefore can move funds on behalf of the deleted canister. I get the canister is gone but is the ability to sign messages as the canister also gone?
I would say so, yes… its gone.
I seem to remember something along the lines that if a canister was deleted that it isn’t really “gone”. Are you still the owner of that canister on the dashboard? I’d so, why not deploy a new canister with methods to access the token?
If you can still access that canister somehow like austin said, tokens are surely recoverable otherwise consider them lost.
One other way could be, dfx canister create - - specified id flag, which creates canister with specific id, i dont know what are base requirements for this method since its not mentioned in docs, but you can try this as well, to create your canister again.
Internet Identity cannot move funds on behalf of that canister.
I actually don’t know how the canister got deleted, investigating.
I’m still the controller but I can’t specific the canister id on deploy on mainnet like local. Doesn’t it automatically select a canister id?
You should be able to set the canister ID you want to deploy to using The canister IDs.json file and the root of your project. If you’re the controller, you should be able to deploy a new canister on top of the old canister ID if you did something with TCEDSA you’ll get the same keys, or if you held tokens with the principal that you should be able to access them if your new canister has the right Async function calls.
My guess is that your canister ran of cycles and you weren’t paying attention for 30 days. This seems to happen to me more than I’d like to admit. 
If the canister gets deleted with an explicit aaaaa-aa:delete_canister then it’s gone and (assuming a correct ledger implementation) the tokens irrecoverable.
Technicality: in this case it’s correct to say that the canister was uninstalled. (It’s an automatic call of aaaaa-aa:uninstall_code) This means the canister and its settings (like controllers) still exist. That is recoverable.
dfx uses canister_ids.json for the mapping. Here’s an example.
Happy to have you around @Severin
another question would be, what happened to the cycles I tried to top to this canister
The canister was uninstalled when the cycles were completely drained, now I have the Funded team and myself trying to recover it
I’ve already spent several ICP from different sources sending the cycles, and I have no idea where the gas is going
If the canister was uninstalled then it will have only a microscopic amount of state left. If you top it up afterwards then it should burn almost no cycles. Are you able to manually check the canister’s status?
My best guess was that it was uninstalled because of the cycle drain attack, but not really sure about that.
I can’t check the status because I’m not a controller, and the controllers can’t give me control because it’s uninstalled. But I can ask them to check that for me, what should we be looking for?
Also where did all the cycles that I sent to the canister went to?
That doesn’t check out from a protocol level. Updating controllers should not require that a canister is installed.
An uninstalled canister should not have anything running that drains cycles so I would expect that basically all of them are still there in the balance