@RHavar may I see what you have tried? I'm interested in this subject. My name for it was "dynamic batching".
I'm not sure it's very useful, as not only did I not get it working -- I'm not sure how to do so. But I think the "project scope" was pretty interesting.
Basically the idea was to build a "commercial wallet" that sits behind a trusted bitcoin node (avoid a lot of validation nonsense and risks etc.). And then provided a really robust API for sending/receiving payments. And I made a very strong distinction between a "payment" and a bitcoin transaction. As in a payment might be: "I want to pay X with N BTC with Z priority" and you could track that payment and see which "bitcoin transactions" it gets reified into (which might keep changing until it eventually confirms).
The other feature I was trying to build which I'm a
huge fan of, is something I call "utxo-giftcards". Where a "utxo-giftcard" is basically a (txid:vout:privatekey). So when you import someone elses utxo-giftcard the wallet knows that it's "untrusted" and that because a 3rd party also has the private key it could be double-spent easily. And a "utxo-giftcard" is considered "redeemed" when the
wallet itself spends it (as opposed to a 3rd party does). And when adding a "utxo-giftcard" you could specify the "redeem priority".
The reason I'm such a huge fan of the idea of "utxo-giftcards" is that it's pretty phenomenally space-efficient (as you can give someone money without even making a transaction) and a death-blow t entire classes of bitcoin analysis attacks. (Of course there are drawbacks in transferring a private-key, but I feel those are pretty obvious and understood enough that it's easy to use what is most suitable)
---
But doing it again, I'd just try have the same interface -- but not try code any of the logic myself -- and instead try use some sort of logical solver -- and then execute the results of that. I think maybe Microsoft's Z3 Theorem Prover could work for it. But don't have the time or energy to try that at the moment