I’ve just now read both the “What is the difference between smart signatures and smart contracts” thread and the “Protecting Funds in Smart Signature Contract Accounts” thread.
I find this intriguing, in part because I’ve been tasked with researching (if not necessarily coding) a periodic (typically monthly, based on real time, rather than consensus time) billing application, similar to the way, for example, an ISP automatically bills a credit or debit card. Rather obviously, if a smart contract were funded by the payor with some lump-sum, and it then delivered funds to the payee on a periodic schedule, it would be no different, from the payor’s point of view, than sending that single lump-sum directly to the payee.
If a smart signature is not a type of smart contract, and “exist[s] off the blockchain,” what exactly is it?
In the “what is the difference” thread, “FrankS” says:
The first way is that it is signed by someone and then sent to someone else. Let us say the Smart Signature is a program that just checks if the associated payment transaction is less then 10 Algo and only occurs once a month.
Can it also check that it’s going to the correct payee?
In the “what is the difference” thread, “Obi” and “ismax” discuss the question of the payor invalidating a smart signature. Obviously, a periodically-billed subscription would need a “cancel” option, preferably one that didn’t involve closing out the account it draws from, so invalidation logic sounds like it would be a good idea. Are there any good examples of how this would work?
The best source is the official Algorand documentation from my point of view:
and the other pages under “Smart signatures”
It depends what you call a “smart contract”.
It is not a “smart contract” as per the definition of Algorand.
But it can be seen as a form of smart contract in a general sense.
A smart signature is not stored per se in the state of the blockchain.
(That is, the code of the smart signature is not stored in non-archival nodes.)
But it appears in the blocks of the blockchain (smart signatures are part of the transaction - more precisely, of the “signed” transaction, if we want to be very accurate.)
A smart signature can check any field of the transaction, including the payee.
You could associate a smart signature with an Algorand smart contract.
The smart signature would require that the transaction is executed in a group of two transactions: one payment from sender to payee, one call of the smart contract from sender.
The smart signature would be use to sign both transactions.
And it will require this is a proper group of transactions.
The smart contract would allow advanced checks, like non-cancellation.
Now, the biggest issue with smart signatures is that it is extremely dangerous for a user to sign smart signatures.
Smart signatures may allow arbitrarily bad transactions for the user, and almost no user (even expert user) has the capability to understand what a smart signature does.
If combined with a smart contract, things becomes even harder to check.
That is why, currently, most wallets do NOT support signing smart signatures. This essentially means you have no way to deploy such a smart signature-based approach to periodic payments to many users, right now.
(Adding such support of signing smart signatures would require creating a list of audited smart signature templates, which is a complex effort, especially from a legal point of view: who is responsible if something is wrong in this repo? Things can go quickly awfully wrong, with all accounts using a bad template fully drained.)
Now, this does not mean that smart signatures are useless. They have many advanced use cases. See Modern guidelines for smart contracts and smart signatures on Algorand - Algorand Developer Portal.
In particular, smart signatures, used as contract accounts (not delegated smart signatures as in the periodic payment case) are similar to Ethereum account abstraction and can be used to provide very advanced wallet features (social recovery, use of FIDO keys, …).
I can certainly understand objections to smart signatures. For my own part, there is only one entity in the world that has pre-authorized withdrawal access to my checking account (The Bureau of the Public Debt, and that only in connection with Treasure Note tenders I’ve explicitly issued), only two that have pre-authorized deposit access to my checking account (my employer is the other), and only one that is authorized to make periodic pre-authorized billings to my debit card (my ISP).
Thanks for the links. I’ll probably be studying them for a while. But all of this raises the question, Is there an approach to periodic billing that doesn’t involve a smart signature, and isn’t, from the payor’s point of view, equivalent to making an advance lump-sum payment to the payee for many months – or even years – of service?
Traditional automatic payments and direct debits are associated with accounts tied to a specific legal or physical entity. Should the payment not go through, there are legal implications.
I think if the aim is to replicate all of that then the task has a broader set of requirements.
Otherwise an “account” (whether delegated via smart sig or smart contract) can be a proxy account specifically for that direct debit or automatic payment relationship.
But how is a proxy account all that different from the payor simply sending a lump-sum?
And what “legal implications” in the case of a payment not going through, other than the payee having the right to suspend whatever service is being paid for? (e.g., it seems like at least once a year, I have to go down to my Credit Union, have my debit card number “burned,” and a new card issued; when that happens, if I forget to change the card number with my ISP, I typically get an email at the top of the month, telling me that the billing didn’t go through, and that I need to update my payment information).
Just had a thought about a “cutting-the-Gordian-Knot” solution to a billing application: something so low-tech, so absurdly simple, that it never occurred to me: Just give the customer full access to a blockchain account, and instructions to fund it at their convenience: The vendor then pulls the specified amount out, at the specified interval, and issues the customer a dunning email if there isn’t anything to pull out. Could even be done without a smart contract, although that would require the customer to either trust the vendor implicitly, or fund the account with exactly enough, just before each due date.
Well if you like, but I would say that is just what I described. A deposit box. I think you are right. Why overcomplicate it?
The only difference is related to KYC and dealing with unmet payments. But even that can be seen as a detail to be adressed technically. At first glance there seem to be all kinds of avenues there too.
My understanding is that something like this could work without a smart contract of any kind (or with something already out there as an API, e.g., one of Circle’s offerings), but that a smart contract would provide an added measure of trustworthiness, by limiting the payee’s ability to withdraw from the proxy account. Am I correct on this?
It depends what you are trying to achieve and of your exact solution.
Note that smart signatures cannot prevent the payee to just empty the account and stop all payments. No solution can actually ensure that the payee will pay every month for the next 4 months.
This is not a blockchain problem: even in traditional finance, you cannot guarantee it (except by suing the payee if they do not pay or if they empty their account so the withdrawal fails).
If you want to be 100% sure the payee will pay for the next 4 months, you have no way but ask the payee the 4 months in advance. If there is no way to cancel the service in these 4 months, then you can as well ask the payee to pay you directly!
An intermediate deposit box / escrow smart contract can be used if you want to allow cancellation at a price (you get reimbursed 80% of the remaining period for example). Otherwise, it is not really useful and direct 4-month advance payment makes the most sense.
I only see one good use case for the smart signature solution (which is completely different from the escrow smart contract solution): you are ok the payee cancels at any time but you don’t want to bother the payee by asking them to sign a new payment every month. And you also don’t want the payee to pay everything upfront. As soon as you want to prevent cancellation or impose penalty on cancellation, the smart signature solution is no more an option.