Quick update on the ledger build instructions: The documentation PR is on review, you can try using this little script to get the canister and the Candid interfaces for now:
This script fetches the ledger canister module that our CI pipeline built. This script will replace the Dockerfile in the first step of the instruction. You won’t need to build the canister from scratch anymore.
dfx canister call ledger_transfer canisterAddress '()'
The Replica returned an error: code 3, message: "Canister r7inp-6aaaa-aaaaa-aaabq-cai has no update method 'canisterAddress'"
It may be worth changing the dfx canister call ledger_transfer canisterAddress '()' command to dfx canister call ledger_transfer canisterAccount '()'. It seems to be working with her.
P.S. Sorry for my bad English
Sorry if I’m missing something, but it seems that I still need to trust the workaround canister (ockk2-xaaaa-aaaai-aaaua-cai) in order to validate transactions on chain?
After doing some digging, the pattern Roman describes in his Community Conversation on canisters holding ICP provides what seems to be a good method for conducting payments onchain (my use case) without querying blocks.
The error seems to indicate that your ledger.did file contains 404: Not Found, which is not valid Candid. I guess there was an error when you fetched it. What command did you use to fetch this file?
@bogwar Can the cycles minting canister give back the specific number of the cycles that it creates when topping up a canister? I know we can call for the exchange rate and make the calculation but it is possible that the exchange rate will change between the top-up call and the check-rate call, so it is better if the top-up call gives-back the number of the cycles that it mints.
Reposting this from another thread for visibility: I need to be notified in my canister when someone pays ICP to it. Is some kind of subscription or event handling feature already implemented? I need this in a grant that just got approved. We were under the assumption that this was implemented already, but I can’t find anything about it.
It is one of the biggest “issues” right now. You can do this by using transaction_notification method in the canister to which the payment that goes into the ledger is initially sent.
This would be a general workflow if going this route:
User calls send_dfx(memo, amount, fee, from_subaccount, to, created_at_time) on Ledger to send ICP to our receiving canister (we’ll break down the parameters of that function call shortly.)
User calls notify_dfx(block_height, max_fee, from_subaccount, to_canister, to_subaccount) .
TxAuth receives the notification from Ledger that was created by our notify_dfx call. We validate the data we are receiving from the Ledger, and add it to our list of authenticated transactions.
There is an example of this in this repository GitHub - sagacards/legends-minter
However, example does not cover any checking of the actual ledger transaction in the canister inside of the transaction_notification method (which you must do to confirm if a payment was properly sent with correct amount to your canister).
Takeaways and issues by using this approach are:
On the client side (javascript), user needs to send two transactions.
First is to send_dfx method of the ledger canister to send ICP for whatever he wants to purchase
Second to notify_dfx ledger canister method after his first transaction was a success (where he would get the actual block number as response that he must use in this call)
If a user navigates away from the client dapp before second transaction has been sent, you would never get transaction_notification called in your canister that got those ICP’s that the user sent in the first transaction, hence not actually being able to check it and send the user whatever he has purchased by his first transaction. This would lead to you having to issue refunds or similar to people that did not complete the full process and / or perhaps state that there are no refunds for the purchases made if users do not complete the complete “checkout” process…
You also need to have a bunch of bloated logic that saves what the user is trying to purchase BEFORE he does the first send_dfx transaction (ie: save his principal or similar and the ID of the item he is trying to purchase so that you can compare the item with that ID price vs how much was sent in that transaction later on in the notification_transaction method once you get a confirmation of a payment back from the ledger. You also need to take care of “double spend” attack perhaps, where user might call notify_dfx with the same block number multiple times, which would make the transaction_notification trigger multiple times for the same transfer.
. Are the instructions in the project correct?