There are basically two Medusa API the user can call:
Let’s call the number of submission in a day $s$ and number of reencryption request $r$.
The basic approach would be to bill each call to these two entry points.
One “submission fee” $f_s$ upon submission of ciphertext.
One “reencryption fee” $f_r$ upon request of reencryption.
This model assumes that clients will always pass via Medusa for reencryption.
That assumption may not always be true in practice however.
If Alice produces the encrypted content and Bob is ready to pay to read it. Once Bob has made the payement onchain, Alice can simply send the private key directly to Bob as long as Bob is sure he can always go through Medusa. In a sense, Medusa acts as a dispute resolution layer in this setting. Bob can wait to receive Alice’s encryption key, and if he doesn’t receive it, it asks Medusa.
→ In the optimistic case, Bob and Alice save cost by bypassing Medusa.
If we call $t$ the number of “intents to decrypt”, we assume $r << t$ and this strategy only captures
$s * f_s + r * f_r$
What we would like to capture as value is
$s * f_s + t * f_r$