Hi,
i just started my staking pool, and now i’m curious to develop something on the chain. Would it be possible to develop this application in plutus?:
I don’t think that is possible because you’d need to sign the delegation certificate on the users behalf. Alternatively, how about … the user delegates to your pool (as normal) and then registers with your smart contract to get an additional benefit, for example to get sent flowers every 10 epochs.
What problem are trying to solve?
If you omit the sending ADA back and forth it is how staking works already.
@wutzebaer might be looking for an “extra” incentive to stake to his pool. Due to economic realities we have now come to an awkward situation where the owner of a pool is give 6x340 => 2040 ADA per month to run two simple servers - way more than is actually needed.
I doubt an investor who is not convinced to delegate to your pool with the security guaranteed by the protocol will trust you enough to send you their money.
The 340 is killing small pools (including mine) and IMO it should be addressed in the protocol parameters not by spo’s wasting their capacities to awkwardly offset that.
That’s not how it would work. Security would still be guaranteed by the network. The coin sent to the contract would be the required minimum (i.e. 1 ADA) to do a meta Tx on the network. This is needed in order for a participant to register him/herself to whatever extra functionality the smart contract provides. Perhaps a fully automated version of this.
Thats why he sends the ada to an adress so the samart contract can stake it for him, i’m just trying to figure out what a smart contract can do and what not… But these actions might spend more fees than rewards are gatered. Is there any other way a User can proof that he staked to my pool?
If the stakepool is willing to provide a fixed rate for the reward (instead of the variable rate that results from the unpredictability in blocks being assigned to the stakepool each epoch), a simple Marlowe contract or Allegra script would suffice.
For example, the “investor” would contribute 1000 ADA to the contract script and the stakepool would contribue 10 ADA to the script at the start of the contract period. Those 1010 ADA would be locked into the script for 10 epochs and payable only to the investor at the end of the 10 epochs. The stakepool would hold the staking keys for the script and all of the staking rewards of the 1010 ADA in the script would acrue to the stakepool operator (not to the investor, who will receive the extra 10 ADA in lieu of the actual rewards amount). The stakepool operator would benefit by having certainty that the ADA would stay staked for the 10 epochs, while the investor wouldn’t experience the variability of epoch-to-epoch rewards or be exposed to the risk of the stakepool being retired. (Such a contract might alleviate investors’ concern and confusion about the high variability of epoch-to-epoch rewards from very small pools.)
The current mainnet supports a clunky version of this contract right now. One would have to create the initial transaction with 1000 ADA from the investor and 10 ADA from the stakepool operator, and then each party would have to sign the transaction before it was submitted to a simple Allegra script that time-locks the ADA and only lets the investor redeem it. The output address for this transaction would combine the payment verification key for the script with the stake verification key into a script address: since cardano-cli does not yet support constructing script addresses that stake, one would have to write a short program to compute the stakeable script address. At the end of the 10 epochs, the investor could submit the transaction that removes the UTxO from the script. The clunkiness comes from the investor needing to use cardano-cli to sign the initial and final transactions.
Variable-rate and multi-period staking contracts like this would be possible with Marlowe or Plutus if one is willing to involve an oracle that monitors staking rewards. One could also construct contracts that didn’t require the stakepool operator to add the reward to the initial contract.
how could one compute the stakeable script address?
Here is a sample Haskell ghci session where a script hash and a stake key are combined into a Shelley address. The example takes the stake verification key in a file stake.vkey and a script with hash 8dc2f25d5fc899e4d43cc0e2993231e1f8da951d5ef4e5566d5c6ab1.
$ ghci
λ> :set -XOverloadedStrings
λ> import Cardano.Api as API
λ> import Cardano.Api.Shelley as Shelley
λ> Right stakeVkey <- API.readFileTextEnvelope (API.AsVerificationKey API.AsStakeKey) "stake.vkey"
stakeVkey :: VerificationKey StakeKey
λ> stakeVkey
"cdf2fb0cdc0b6ecda2612b3fb8bf84a4814ffcd238b92fa7a6a35f5c5c0588da"
it :: VerificationKey StakeKey
λ> Just scriptHash = API.deserialiseFromRawBytesHex API.AsScriptHash "8dc2f25d5fc899e4d43cc0e2993231e1f8da951d5ef4e5566d5c6ab1"
scriptHash :: ScriptHash
λ> scriptHash
"8dc2f25d5fc899e4d43cc0e2993231e1f8da951d5ef4e5566d5c6ab1"
it :: ScriptHash
λ> addr = API.makeShelleyAddress API.Mainnet (API.PaymentCredentialByScript scriptHash) (API.StakeAddressByValue . Shelley.StakeCredentialByKey $ API.verificationKeyHash stakeVkey)
addr :: Address ShelleyAddr
λ> addr
ShelleyAddress Mainnet (ScriptHashObj (ScriptHash "8dc2f25d5fc899e4d43cc0e2993231e1f8da951d5ef4e5566d5c6ab1")) (StakeRefBase (KeyHashObj (KeyHash "2ae7efb21f510084da0d1e7419dfc9461246d3057d3d7e6a1d9855ea")))
it :: Address ShelleyAddr
λ> API.serialiseAddress $ API.AddressShelley addr
"addr1zxxu9ujatlyfnex58nqw9xfjx8sl3k54r400fe2kd4wx4vf2ulhmy863qzzd5rg7wsvalj2xzfrdxpta84lx58vc2h4q7q5swn"
it :: Data.Text.Internal.Text
I’ll write up an end-to-end example in detail and post it in this thread in a day or so.
I wrote up an end-to-end example for time-locking ADA into an Allegra script that stakes. This includes a bash script and example transactions on testnet. (I’ll update the write-up in 3 epochs, after the staking rewards have appeared on testnet.)
Until wallets support signing scripts, an “investor” would have to use cardano-cli to perform a couple of the operations; they would also have to inspect the script and initial transaction to ensure that it would behave as promised.
wow thank you for sharing you knowledge