Sidedoor

To reach the next billion users in web3, we need to bring them in the side door. Sidedoor is collection of web2-style REST APIs, enabling businesses to add web3 features and functionality to their users without requiring wallets,interfacing with RPC endpoints, sending transactions, paying gas, etc.

The first set of Sidedoor API endpoints enabling real-time streaming of tokens, powered by the Superfluid protocol, along with related enpoints for Authentication and Wallet creation.

Note: currently supported on the Goerli testnet.

API URL

All endpoints are available at https://api.sidedoor.tools.

Wallets

If the user doesn't have a wallet address, one can be created via an API endpoint!

• GET /wallets/safe/new - This endpoint will create a new Gnosis Safe smart wallet. By default, the Safe has two owners: 1) a Sidedoor "hot" wallet that is used on the server side to send transactions on behalf or users, and 2) a Sidedoor "cold" wallet that serves a backup. If the user calling the endpoint already has an address, it will become a thrid owner of the Safe. The Safe is a "1 of x" multi-sig, where any single owner can sign transactions.

Authentication

Most API endpoints require authentication in the form of an API key sent as Bearer token in the header of each request. These keys are designed to be "per end user", rather than "per app". For endpoints that involve transactions such as moving tokens, an additonal one-time-password (OTP) is required, as generated by the user's authenticator app (ie. Google Authenticator, Authy, etc.). The following endpoints faciliate user creation, api key generation, and authenicator seeding.

• GET /auth/user/new - Parameters: email (required, valid email address) and address (required, wallet address). This endpoint stores the address and email in a server-based database and generates a secret, which is also saved. The secret is used to generate a one-time-password which is emailed to the user to verify their email address.

• GET /auth/check - Parameters: otp (required, one-time-password from email verification or authenicator app), address (required, wallet address). This verifies that the OTP is valid. If the user does not yet have an API key, this confirms their email address is valid and an api key is generated and saved to the database. In any event, if the OTP is valid, the response includes the api key for the user, which can then be saved in an app or dapp for future use.

• GET /auth/qrcode - (Api key required) Parameters: format (optional, "image" for image response). This endpoint faciliates the setup of an account in an Authenticator app. The JSON response includes a base64-encode data/image that can be used to render a QR to the user, which can be scanned by Authenticator apps to add the account. A base32 element in the response contains a base32-encoded key that can be manually pasted into Authenticator apps, when scanning a QR isn't feasible. Note that setting the optional format parameter to image, this endpoint will respond with the QR code image itself, instead of a JSON response, which may be convenient for apps to quikcly display the QR code to the user.

Streams

Streams are created using the following endpoints using the Superfluid protocol via Token Vesting Vestor contracts, which enable streams with future start times, predefined durations, and lump sum payments.

• GET /streams/vestor/new - Parameters: otp (required, code from Authenticator app), token (required, address of Super token to be streamed). This endpoint deploys a Vestor contract dedicated to the user.

• GET /streams/vestor/deposit - Parameters: otp (required, code from Authenticator app), vestor (required, address of user's vestor contract), token (required, address of underlying non-super token to be deposited), amount (required, amount to be deposited, considering decimals for the token).

• GET /streams/flow/new - Parameters: otp (required, code from Authenticator app), vestor (required, address of user's vestor contract), recipient (required, address to receive stream), flowrate (required, tokens per second to stream), start (required, unix timestamp), duration (required, seconds), lumpsum (optional, lump sum amount to transferred -- not streamed -- at start time), ref (required, text label, converted to bytes32 server-side). This endpoint creates a Flow on the Vestor contract to the recipient. If the start time is now or past, the stream will be launched at the time the endpoint is called.

• GET /streams/flow/replace - Parameters: same as for /streams/flow/new and the ref value must match the Flow being replaced. This endpoint will replace an existing Flow to a recipient with a new one that may have different values for flowrate, start, duration, etc. The endpoint will stop the existing Flow and add a new one with given parameters.

• GET /streams/flow/stop - Parameters: otp (required, code from Authenticator app), vestor (required, address of user's vestor contract), recipient (required, address to receive stream), ref (required, text label). This endpoint will stop a Flow to the recipient with a matching ref value.

• GET /streams/flows - Parameters: vestor (required, address of user's vestor contract). This endpoint will list all active flows (started and not-yet-started) for the Vestor contract.

TODO:

• change some endpoints to POST
• multi-chain support, including mainnets
• payment flows, both saas + funding
• support for multiple Flows per recipient address
• grant role on Vestor to user address
• take custody workflows for Safes (verfiy address, then add to Safe as owner)