Init Payment Delegation DB doc

[Spacesai1or]

The corresponding developer guide code is here

This PR inits the Payment Delegation DB docs that covers how to use the register-payer and add-users endpoints for the Relayer API

CC @alexvotofuture

[netlify]

✅ Deploy Preview for lit-dev-docs ready!

Name	Link
🔨 Latest commit	5b51d80
🔍 Latest deploy log	https://app.netlify.com/sites/lit-dev-docs/deploys/666142d4d419dc00084fc41a
😎 Deploy Preview	https://deploy-preview-300--lit-dev-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[joshLong145]

Nice setup :)

[joshLong145]

We should add that API requests using the "payerSecretKey" requires secure context. Should not be used from a browser context.

[Spacesai1or]

Added: API request using the 'payerSecretKey' requires secure context, meaning it should not be used from a browser context where it would be leaked to the end user.

[alexvotofuture]

Awesome guide! Some feedback here before launching:

• The title of this guide is "Payment Delegation Database", but then the guide is all about using the Relayer's new endpoints. Should we just call this "Paying for Lit"? Or "Paying for users with Lit Relayer"?
• We should put the "Paying For Lit" section right at the top, to explain why the whole guide is relevant to the user. Then, when that section ends, follow it with the current first paragraph. Then we can move onto "Prerequisites".
• Perhaps we should call out that this is all to help the developer allocate capacity for the user, so that they do not have to deal with additional steps to take advantage of Lit?
• We mention requiring an understanding of the relayer server, but the link just leads to the GitHub repo. Do we have any other documentation for it that we can link to? If not, should we quickly explain what the relayer is and what it does, so that the guide has that knowledge embedded?
• Is understanding Chronicle actually a pre-requisite, or can people get through this and use the tool without understanding it?
• In "Prerequisites" we write "This can be obtained by filling out this form" but there is no hyperlink. Same with the line in "Adding users as payees". Let's add those.
• Auth Signatures are mentioned in "Paying for Lit" - is that still relevant/correct with Auth Unification in place?
• [n00b question] - if the payerSecretKey is meant to be kept private, is the assumption that wherever this code is running is a centralized server run by the dApp developer? Might be helpful to call out that assumption if so, and provide suggestions at the end of the guide on how to hide the payerSecretKey if the code is not being run in a private environment.
• It would be helpful if, at the end of the guide, we explain what the developer will have just accomplished, how this will affect the app (ex: "All actions taken by the user that involve Lit and require Capacity Credits will have those Capacity Credits covered by the payer, reducing complexity for the user.), and any next steps the dev needs to do with regard to renewing capacity credits, topping up accounts, etc.

[Spacesai1or]

Perhaps we should call out that this is all to help the developer allocate capacity for the user, so that they do not have to deal with additional steps to take advantage of Lit?

@alexvotofuture I added this sentence to the last paragraph of Paying for Lit section:

This streamlined process offers a more robust way to delegate capacity to your users, without having to micro-manage Capacity Credit delegations.

---

We mention requiring an understanding of the relayer server, but the link just leads to the GitHub repo. Do we have any other documentation for it that we can link to? If not, should we quickly explain what the relayer is and what it does, so that the guide has that knowledge embedded?

We don't have any additional docs on it. I added:

- Lit's [Relayer server](https://github.com/LIT-Protocol/relay-server)
  - The Relayer is a centrally ran service by the Lit Protocol team to facilitate and subsidize some interactions with the Lit Protocol smart contracts on Chronicle.
  - In this guide the Relayer does several things for you including:
    - Acting as a gateway to the Chronicle blockchain
    - Generating new `payer` wallets when you request to register one
    - Handling the blockchain transactions to:
      - Register the new `payer` wallet with the Payment Delegation Database smart contract
      - Mint Capacity Credits for the new `payer` wallets
      - Add users as `payees` for your `payer` wallet

---

Is understanding Chronicle actually a pre-requisite, or can people get through this and use the tool without understanding it?

No it's not, I removed since it's also linked in the previous sections

---

Auth Signatures are mentioned in "Paying for Lit" - is that still relevant/correct with Auth Unification in place?

Yes, AFAIK Auth Sigs are still used as proof you are delegating a credit to someone

---

if the payerSecretKey is meant to be kept private, is the assumption that wherever this code is running is a centralized server run by the dApp developer? Might be helpful to call out that assumption if so, and provide suggestions at the end of the guide on how to hide the payerSecretKey if the code is not being run in a private environment.

Yes, the code that's interacting with the Relayer and submitting the secret key would be on the dev's backend and not where some unauthorized party would have access to it. I added the following to the warning message in Registering a Payer Wallet as Josh suggested: API requests using the 'payerSecretKey' requires secure context, meaning it should not be used from a browser context where it would be leaked to the end user.

I also added this warning to the end of Registering a Payer and the beginning of Adding Users as payees sections:

:::warning
Remember that `payerSecretKey` is essentially the private key to your new `payer` wallet and should be handled securely. It **cannot** be recovered by Lit if you loose access to it, and you shouldn't make requests using it in a context like the browser where the end user would have access to it.
:::

---

Regarding,

and any next steps the dev needs to do with regard to renewing capacity credits, topping up accounts, etc.

I asked in Slack, but I think this is TBD

I added this as a Summary:

## Summary

This guide has showcased a new way to handle delegation of Capacity Credits to your users. Instead of manually minting Capacity Credits and managing the delegation of those credits to your users, you now have an understanding of how to use the to new API endpoints on the Lit Relayer server to:

1. Register new `payer` wallets using the `/register-payer` endpoint
   - Requests to this endpoint will create a new `payer` wallet, register it with the Payment Delegation Database smart contract on Chronicle, and will automatically mint a Capacity Credit for it
2. Adding users as `payees` to your `payer` wallet using the `/add-users` endpoint
   - Requests to this endpoint will grant capacity to use the Lit network to the users you specify
   - All requests to the Lit network that require payment, such as decryption and execution of Lit Actions, will be paid for by your `payer` wallet on behalf of the `payee`, reducing the friction of connecting your users to the Lit network

:::warning
One last final reminder that your `payerSecretKey` is effectively the same thing as a private key, and needs to be handled securely. Any code that uses your secret in plaintext should only be accessible to authorized parties. Requests to the Relayer that use your secret key should not originate from the browser where end users would have access to your secret key. Typically, the code that interacts with the Relayer is going to live on your backend.
:::