I have an application which needs to distribute payment for a physical product to the shop owner (O) and the artist (A). I am planning on using a multi-sig wallet and a creating pre-signed draft transaction that will transfer the funds from the payment from the receiving wallet to the wallets of the host(O) and artist (A).
I am thinking of using Stacks to monitor the wallet address for the incoming payment and I’m hoping that Stacks can then tigger a contract to broadcast the pre-signed draft transaction to the bitcoin network once the funds arrive and thus complete the transaction and send the funds to the final recipients.
(I would also use Stacks to create an NFT of the physical product but this is probably not relevant to my question)
Is this flow something that Stacks would support in its current form?
Many thanks in advance.
Hey 2oby, you can look at chainhooks from Hiro as a tool to watch for on chain events and respond to them. You can then use a server side / custodial wallet software to broadcast transactions and sign or partially sign them too if the private key is secure. Clarity contracts can’t sign or broadcast directly as they have no way of controlling a private key and have no access to network protocols like http.
Many thanks for the answer.
I was hoping that I could pre-sign the transaction and then store it within a Clarity smart contract to be broadcast to the network when conditions were met (i.e. incoming funds to a wallet address).
I am surprised that this does not seem to be possible in a ‘pure’ bitcoin ecosystem.
I see. You could store the PSBT etc in a smart contract but to broadcast it you’d need some client software to read ad broadcast!
Hi, thanks, yes this seems to be a limitation with other layer 2’s as well.
Seems like more of the logic is going to have to be off-chain.
for multi-sig wallet, you can look into using Asigna https://twitter.com/asignaio which supports bitcoin, ordinals and Stacks.
The buyer could send a BTC payment to the Bitcoin multisig address owned by O and A, and then post a Merkle proof of the existence of this transaction along with a copy of the transaction itself to the smart contract. The smart contract, upon validating the proof and transaction structure(*), would then create for the buyer a proof-of-purchase for the physical good (e.g. as an NFT). Would that serve your needs?
Once sBTC comes online in 2024, then buyers could just send sBTC to O and A’s address. Later, O and A would collectively peg-out the sBTC for BTC.
(*) the contract itself would verify that the proof is valid, verify that the transaction has never been processed before, and verify that the transaction decodes to a well-formed payment to the right address for the right amount.
Could the buyer transfer funds through the sBTC bridge to a Stacks smart contract address, where the distribution between parties and the minting of the NFT are managed?
Many thanks for the idea. I will have to look into this.
I am just reading about sBTC. This seems like it is the best option.
So the flow would be something like:
- Buyer sends BTC to a the BTC address of a stacks smart contract.
- Clarity scripts mints NFT, sends assigns to Buyer and distributes funds to Os and As sBTC wallets.
- O and A ‘peg out’ and convert sBTC to BTC
I don’t love step 3, Is it not possible for the Clarity Smart Contract to do the pegging out itself and convert the sBTC back into BTC and send this to O and As wallet?
You could do this in step 2 if you wanted. As part of buying the NFT for sBTC, the Clarity contract executes the peg-out operation for the received sBTC before sending over the NFT to the buyer.
Oh! That would be perfect. I didn’t realise the Clarity Contract could do that itself? Up until now all the solutions I have looked at seem to need some offchain automation broadcasting the draft transaction. (e.g. monitoring the multisig wallet for the arrival of the funds then broadcasting the pre-signed draft transaction)
Do you happen to have any examples or links to the docs where something like this is happening?
(Background: the intention is that once the smart contract is set up, it can sit forever, waiting for the payment. There should be no dependencies on external systems, servers, apps, etc. The mobile app and backend, are just convenient ways of creating contracts, browsing artwork and initiating the payment, but any transfer of sufficient funds into the wallet associated with the contract will execute the transfer of the NFT and distribute the funds.)
sBTC isn’t built yet, but the sBTC-to-BTC withdrawal process will be handled by a contract-call. So, it’s entirely doable within a Clarity contract. It wouldn’t be much of a 2-way peg if this wasn’t possible
It wouldn’t be much of a 2-way peg if this wasn’t possible
agree. But I was very surprised to find that this use case was not supported (anywhere, not just stacks) without multi chain bridging and off chain monitoring… seems we really ARE still very early
2oby, take a look at a thread from the Zest Protocol founder about OP_DROP. Here’s the link: https://twitter.com/TychoOnnasch/status/1717542694199718161. The key point is that your Bitcoin can be deposited directly into a smart contract in a single transaction. We’re all discovering together what sBTC will be capable of!
I took a look at the ‘Tweet’, this sounds very promising… but the thread was light on details—unless I was looking in the wrong place… any more info would be great!