📝 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

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.

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?

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.

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.

Describe the bug
I am attempting to install octane via the instructions documented here:
https://github.com/solana-labs/octane/blob/master/docs/library.md#install
I attempted using an existing repo as well as a new blank repo. I am using yarn v3.5.0.

To Reproduce
Steps to reproduce the behavior:

1. Create new repo initiated with yarn init
2. Attempt to install octane with provided instructions
3. See error:

Usage Error: It seems you are trying to add a package using a https:... url; we now require package names to be explicitly specified.
Try running the command again with the package name prefixed: yarn add my-package@https:...

4. Attempt to reinstall by prepending octane-core@ to the install command per error
5. See next error:

➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: octane-core@https://gitpkg.now.sh/solana-labs/octane/packages/core?[...] isn't supported by any available resolver
    at xf.getResolverByDescriptor (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:391:1647)
    at xf.bindDescriptor (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:391:1036)
    at _ (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:439:6900)
    at async Promise.allSettled (index 0)
    at async to (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:390:10398)
    at async /Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:439:8205
    at async Ge.startProgressPromise (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:390:47579)
    at async je.resolveEverything (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:439:6233)
    at async /Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:442:2137
    at async Ge.startSectionPromise (/Users/warly/.cache/node/corepack/yarn/3.5.0/yarn.js:409:3292)
➤ YN0000: └ Completed
➤ YN0000: Failed with errors in 0s 14ms

6. See that nothing has been installed to the node_modules folder.

Expected behavior
The package should be installed in node_modules as expected.

Screenshots

Desktop (please complete the following information):

• OS: macOS Ventura v13.2.1
• Browser: N/A

Additional context
I tested with yarn in an empty repo for creating this issue, however I prefer using pnpm. Until the octane library is on NPM it would be helpful to have more complete install instructions for different package managers. Ideally it would be on NPM so devs could just run pnpm add @solana-labs/octane (or preferred package manager equivalent).

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.