I had a look at the Delandlabs DFT standard, I’m not sure I can contribute anything meaningful to that project. Its complexity is way over my head, I just want to have a consumer-side abstraction for receiving tokens, I don’t care how the rest of the token works. Any way of sending them out again is fine with me, really. I’m also completely new in this community and have no connections.
Anyway, here’s some Candid code for the receiver interface:
type FungibleTransaction = record {
CreditedSender: principal;
Receiver: principal;
Message: opt blob;
Amount: Nat;
};
type TXError = nat8;
service FungibleToken {
"ft_send": (Transaction) -> (opt TXError);
}
service FungibleTokenReceiver {
"on_ft_received": (Transaction) -> ();
}
During sending, the sender can specify a sender account to be credited for the payment (when paying on someone else’s behalf), but the tokens are deducted from the caller’s account. The sending contract must try to call on_ft_received function on the receiver. If the receiver does not have such a function, or is not a canister, the resulting error should just be ignored silently. The on_ft_received event handler can be called by anyone, and must interpret the caller’s principal as the token type (usually, the caller would be the token ledger canister currently executing ft_send). Since the caller cannot be faked (to the best of my knowledge), the data is considered reliable, as long as the caller itself is trusted.
Now, whoever wants to be able to receive the tokens and be notified about it just needs to implement the event handler, but this is entirely optional. Users will probably need some different kind of subscription or have their own wallet canister or just do polling or whatever. This is not my concern here and can be solved by other standards. All I want to solve here is that canisters can easily receive money. No need to check for double spends, pool known TXs, query other canisters, etc.