@bitcoincashautist reviewed the contract and agrees it would work as intended! 
He catched a few sloppy mistakes I made so I just fixed them in the Cashscript code, thanks @bitcoincashautist ! 
One mistake he found was non-obvious to me from the Cashtokens spec, that OP_UTXOTOKENCATEGORY doesnât push any capability for an immutable NFT. Whereas I had assumed (and interpreted from the spec) that it would push a 0 
I was reviewing and rewriting it in Script Assembly using BitAuthIDE, finished just now, here it is:
Script assembly version of Flipstarter v2 contract from here:
www.github.com/mr-zwets/p2shAssuranceContract
Note: upon loading this template, you must edit scenarios and manually replace the bytecode stored pledge receipt NFTs with bytecode matching the temporary keys generated by your browser.
For this, z_helper script is provided, from where you can copy & paste the hex
With the Cashscript v0.8.0 prerelease and the publication of cashc@next itâs now possible to compile the cashscript assurance contract upgraded with the CashTokens functionality down to bytecode!
They are just slightly bigger than their v1 counterparts with all the new cancel-any-time functionality.
v2 is 101 opcodes and 165 bytes (without constructor arguments) in size, compared to the 95 opcodes and 150 bytes of v1.
Next up is upgrading the Cashscript SDK so you can easily make transactions with the new token-features on chipnet.
With the proper Cashscript v0.8.0 release itâs now possible to use the CashTokens version of this contract on the Bitcoin Cash mainchain! With the upgraded SDK and the upgraded Cashscript-Playground itâs now easy to make transactions using the smart contracts functions.
There could be a non-custodial webapp for this that connects to the Paytaca browser extension for the smart contract functionality.
So Iâm using a p2sh contract utilizing the new TransactionBuilder class in Cashscript v0.8.0 on BCHouse based on the v2 p2shAssuranceContract.
Overview
The main difference from the v2 assurance contract is that Iâm using several variations of the contract to allow deposits from non-WalletConnect wallets. This makes it:
The design of the contract is tailored more for platform usage though, since the address the user pays to is a covenant that requires the transaction spending the deposit to pledge the funds with the campaign utxo and output an NFT receipt (exactly like Mathieuâs v2 assurance contract) OR return the funds immediately.
So due to this covenant design, either the userâs wallet, the web browser, a platform like BCHouse, or an independent 3rd party (like unspent-phi) must execute the transaction. The web browser and the platform are in the best position to do that given the contract parameters.
Payment Requests
I go through the extra step of using BIP70, JPP, and JPPv2 on BCHouse to provide the contract parameters both in the memo field and url for users - allowing them in the worst case to recover from any potential issues with the platform. Some wallets like Bitcoin.com only provide the payment url to users after the fact while others give access to both the url and memo, so I had to use both unfortunately which can be a problem with legacy QR code readers.
Future work
Either way, a simple link to a 3rd party before payment can provide the contract parameters, for example, a separate site on IPFS like this implementation. An even better solution, is using a CashRPC implementation with the same parameters to store and verify the contract and destination address before funding, as well as act on the contract/utxos.
Additionally, the design of both v2 assurance contract and the BCHouse contract donât allow for compatibility with anyonecanpay type of pledges. This is something that could be fixed by requiring any âover-pledgingâ to be returned to the pledger immediately and allowing payouts IFF the outputs match the campaign goal as opposed to the campaign utxo value being >= the campaign goal:
So: require(output[0].value === fundingGoal) not require(input[0].value >= fundingGoal)
Anyways, thereâs a lot to be desired from my implementation for both wallet connect and non-walletconnect users. I havenât really made this contract available for users on mainnet (minus my own tests and campaigns) for these reasons.
In June, a new project by @SayoshiNakamario was launched, building further on the smart contract Flipstipstarter idea/contracts. Itâs called fundme.cash and it is a platform for crowdfunding which uses walletconnect to pledge & cancel pledges.
Itâs already starting to gain usage, with fundraiser number #7 recently launched being by @BitcoinCashPodcast.
The contracts, written in CashScript, are publicly available on github in this repo: https://github.com/SayoshiNakamario/CashStarter.
Yeah absolutely, and now weâve seen another one from Paul as well too.
The ecosystem is just ripping up level after level at the moment, while the rest of the world remains quietly unaware. But the pace is really impressive and by the time it becomes public knowledge we will be so far in front there will be no chance of catching up and everyone will have to switch.