Describe the bug Even after following SETUP.md step by step, the current vercel deployment does not work.

To Reproduce Steps to reproduce the behavior:

1. Follow SETUP.md, and update values in config.json with mint and authority pubkeys.
2. Commit those to the fork.
3. Deploy with env variables SECRET_KEY, RATE_LIMIT, and RATE_LIMIT_INTERVAL.

Expected behavior The deployment works.

Screenshots

Desktop

• OS: macOS Monterey
• Browser: Chrome
• Version: 102.0.5005.115

Additional context I'm guessing because of the recent changes (adding lerna), it does not build properly on Vercel, even with lerna.json in the root directory.

The rate limiter middleware's default key is req.ip but there doesn't appear to be a property called ip on the request that we pass to it here. The actual object we give it is an IncomingMessage and the IP is available as socket.remoteAddress or in the headers.

In this PR, we teach the rate limiter middleware to source the IP address from the x-real-ip header first, and the remoteAddress on the socket second.

I have deployed octane successfully on Vercel, and when I go to the app/api I can see the fee payer and token account/mint all good!

The fee payer wallet has SOL to pay for the fees, however, when I try to send my custom token it still says: "YOU DON'T HAVE ENOUGH SOL"

Any idea why is happening?

is there a minimum of SOL that I need to hold on the account? or something else?

Hey!

In this PR:

• I've moved most of the transaction logic (validateTransfer, validateTransaction) from API controllers to /src/actions/. It allows developers to use octane as a library, while keeping the web service mode. It also makes testing much easier.
• I also refactored API controllers from Vercel functions to Next.js. It probably should be in a separate PR, but I've figured that out too late. Since it wasn't a big change and given the alpha status of the library, I decided it could be merged together with transaction logic separation. If you decide it would be a bad move, I can move it out to a separate PR.
• I moved parts of code that depend on local context (like env.ts and connection.ts) to /src/helpers. The idea is that core should be context-independent and configured only through argument. However, if an app uses octane as a library, they might choose to opt-in and use some of the helpers for configuration.
• I added testing setup and added first two tests.

Tests and library setup were commited separately, if you would like to review it subsequently.

Someone running Octane should be able to accept multiple tokens (could be USDC, USDT, mSOL, or anything else) with different fees denominated in each.

This change necessitates moving the configuration to something more flexible than environment variables. We still want to use Vercel's encrypted env vars for the secret key and some other parameters.

Currently, Octane doesn't support transaction that are submitted from client. Such transactions could be used to drain fee payer by requesting many transactions, breaking the state for them (for example, by withdrawing all of the tokens), then submitting them to the network with skip-preflight options. Fee payers get charged, but transaction fails.

For some fee payers, spending these fees could be tolerable and, basically, "cost of doing business". This PR introduces a non-default config option. When enabled, transfer and createAssociatedTokenAccount endpoints return signatures, instead of submitting transactions. buildWhirlpoolsSwap in this case will return pre-signed transaction, so sendWhirlpoolsSwap can be omitted.

The config option could be:

"returnSignature": {
    "type": "allowAll"
}

This way, all transactions will be allowed.

Alternatively, this config option will only pre-sign transactions if user passed reCaptcha validation:

"returnSignature": {
    "type": "reCaptcha",
    "reCaptchaProjectId": "",
    "reCaptchaSiteKey": "",
    "reCaptchaMinScore": 0.5
},

In this case, node operator has to set RECAPTCHA_API_KEY variable and pass reCaptchaToken with request.

This doc is basically an intro to Octane for various use cases.

Developers can skim through it to get a basic understanding of the process and then refer to library reference / API endpoint list.

This PR introduces gasless swaps to SOL from selected tokens using Whirlpools!

It works through two actions/endpoints:

• buildWhirlpoolsSwap
• sendGeneratedTransaction (or, if you use octane as a library, signGeneratedTransaction)

The first endpoint builds a transaction for user to sign with pre-filled Whirlpools instructions. The second endpoint signs it from fee payer's side and submits the transaction to network.

The implementation leverages MessageTokens that provide anti-tampering capabilities, while keeping Octane stateless. More context is available here: packages/core/src/actions/signGeneratedTransaction.ts

Previously I introduced an option to send transaction via your own RPC endpoint. However, it allows a "bad state" attack: user can request a signature (passing the simulation), then break the conditions for transaction success (for example, by withdrawing all of the tokens), then submit the transaction with no-checks option and previously received signature. The transaction will fail, but the transaction fee would be spent regardless.

This PR introduces an action that creates an associated token account if end user paid a fee in SPL tokens. Both Octane server and Octane core will support this operation.

Creating account requires to transfer "a rent-exempted minimum" of SOL. Regular Octane /transfer endpoint won't approve this transaction since it requires to spend more SOL than just the transaction fee.

When offering these endpoints as a node operator, make sure to set a bigger price that covers rent-exemption minimum.

An example use case: a user without SOL wants transfer SPL tokens to a friend, who never received these (or any) tokens before.

Every Octane instance requires an account that accepts tokens and stores SOL for user's transactions. Naturally, amount of SOL decreases and balances of tokens increase. Node operators have to regularly swap tokens for SOL to keep node operational. Additionally, node operators have to create associated token accounts for each token they receive and setup pricing settings for each token individually.

This PR adds a CLI for server instance and core functions for library users to automate most of the management errands. CLI & new PayerUtils core export allow to:

• Build token config from most popular tokens in Jupiter exchange and general pricing strategy by setting a margin on top of fees
• Create new token accounts for items in config
• Swap tokens to SOL using Jupiter exchange

seva@Sevas-MBP octane-upstream % yarn run cli
[...]
Usage: cli [options] [command]
Options:
  -h, --help                                   display help for command
Commands:
  create-config-with-popular-tokens [options]
  create-accounts [options]
  swap-tokens-to-sol [options]
  help [command]                               display help for command

Some notes on implementation:

• packages/server/next.config.js adds new entrypoint to Next.js builder. It seemed to be the only way to integrate CLI into the app without bringing new build config.
• Jupiter is used through HTTP API because the JS SDK requires a certain spl-token version and generally a non-lightweight dependency.

Is your feature request related to a problem? Please describe. Solana will in the near future introduce more complex transaction fee pricing and there won't be a singular "lamports per signature" value. Transactions will be priced more accurately based on the compute units they consume.

Describe the solution you'd like Octane would need to pull the fees from the chain for each transaction as it isn't reliable to assume a fee in advance. This is not an issue right now but for future proofing this is important.

Is your feature request related to a problem? Please describe. Currently the only endpoint is transfer which will pay Octane with an SPL token. This requires the operator of Octane to periodically replenish their wallet with SOL.

Additionally, transferring SPL tokens is nice, but doesn't easily give the user a way to get SOL, which they could use for their own transactions that may require more flexibility.

Describe the solution you'd like An endpoint that allows swaps from SPL tokens to SOL -- for example, using Serum's upcoming Swap instruction or an AMM -- could allow Octane and the user to receive SOL.

Is your feature request related to a problem? Please describe. There are no tests for the endpoints. It would be nice to know that they work!

Describe the solution you'd like At minimum, integration tests for the API routes would help validate existing expected behavior. Everything else is kind of a private interface but we could still unit test.

Describe alternatives you've considered YOLO to mainnet with no tests, introduce breaking changes, and mute Github notifications.

📝 Note: Implementing #1 would pretty much solve this too, with some light tweaks.

Preamble

Consider this code that's designed to prevent attackers from spamming Octane's generous offer to sign and simulate a transaction:

https://github.com/solana-labs/octane/blob/master/src/api/transfer.ts#L23-L32

That code uses a module-local Set to track which source accounts have in-flight transactions:

https://github.com/solana-labs/octane/blob/master/src/api/transfer.ts#L7

Problem

Consecutive requests from an attacker are likely to hit the same thread/instance of the serverless function, but from what I understand this is not guaranteed.

From the Vercel docs:

For example, a Serverless Function handles an incoming request, runs some computation, and responds. If another request comes to the same path, the system will automatically spawn a new isolated function, thus scaling automatically.

In contrast, processes and containers tend to expose an entire server as their entrypoint. That server would then define code for handling many types of requests.

The code you specify for handling those requests would share one common context and state. Scaling becomes harder because it is difficult to decide how many concurrent requests the process can handle.

If consecutive requests by the attacker hit different threads running our serverless API function, they will each have different Sets of source ids, and will permit the simulation/broadcast on each thread, rendering the defence mechanism ineffective.

Possible solution

In general, with horizontally scalable systems of lambdas, you can rely on a shared state service to implement a mutex. We could consider building in support for something like Upstash – a Redis service. We could implement the source account lock as a [Redis distributed lock[(https://redis.io/topics/distlock).

https://docs.upstash.com/redis/howto/vercelintegration

Preamble

The internet is a jerk. Sometimes connections go down. Requests rebroadcast as clients retry. Retry logic is often unsophisticated.

Problem statement

We have logic in Octane to prevent malicious consecutive signing requests (through locks) but we might also consider protecting against accidental dupes.

There are many reasons why a client might accidentally re-send a request.

• It disconnected after sending the first request, but before receiving the response.
• A fatal in the response handler re-triggered the request.
• It's dumb.

Proposal

Require, as part of the transaction signing request API, that clients supply an idempotence token. Octane would store this token in a distributed storage system like Upstash (Redis). If Octane encounters a signing request having an idempotence token that it has seen before, it drops the request.

Details

• It's important that the idempotence token be universally unique. In practice, this will probably look something like Octane taking whatever #yolo idempotence token the client sends and hashing it together with the transaction itself to create something unique. If a client insists on reusing idempotence tokens (eg. '') multiple times with the exact same transaction, it's gonna have a bad time.
• The distributed data store probably needs to store three states for each idempotence token:
  • Nothing stored (never seen this transaction).
  • in-flight when the transaction has been received and validated, but not yet confirmed.
  • expended when the transaction associated with this idempotence token has been confirmed.