Context
After having written a proof-of-concept of a closed-source java SAAS app, I would like to raise a "relatively" small investment to refactor the code-base to allow the scope of the app to be increased. To minimise the amount of trust required and resources allocated to administrative tasks and "business plans", I would like to allow people to invest with a predetermined maximum return on investment that is preset in a smart-contract investor_payments
, where e.g. 60% of the SAAS revenue is returned directly to the investors and 40% goes to me, until the investors are made whole. E.g.
- For investments of the first $0 to $5.000,- the investors may receive their input back with a multiple of 10.
- $5.000,- to $25.000,- have a maximum ROI factor of 5.
- $25.000,- to $50.000,- have a maximum ROI factor of 2.
Transaction Description
The SAAS app is centralised and gets updated throughout the investment process. However, its users need to provide the app/.jar file with their proof of payment to the smart contract user_payments
, to use it. The user_payments
smart-contract automatically splits the user-payments into investor returns and SAAS-developer returns (through the investor_payments
contract), according to the distribution key set in the investor_payments
contract.
Limitations
The investors still need to trust me/the developer of the SAAS app to not change the "wallet address" of the user_payments
in future updates of the app. I think this is a fundamental limitation on the concept as one could always start "something else" which happens to be very similar whilst using a different wallet address at the cost of reputation.
Question
I doubt I am the first person to try something like this, and I was wondering whether there are any example contracts that provide this functionality/I could use as a starting point. And more importantly, for SAAS fees in the range of $1 to $10 a month per user, would the Ethereum eco-system be suited for the proposed investment contract, for example by off-loading transaction handling into layer two solutions, or would it perhaps be wiser to build this smart-contract on another chain or in some hybrid form?