# Ottersec Audit Scope
The Audit covers a simple on chain fee program and a more expansive set of WASM modules as part of our new Signer release.

## Signer Overview
The system uses a custom hardware and software implementation, combining a Hardware Security Module (HSM) with Trusted Platform Modules (TPM) on dedicated server hardware. It's a non custodial, fast signing and key management software. Key security features include:

- Secure boot process: Only pre-authorized firmware, kernel, and application versions can access the identity key controlled by the TPM.
- Unikernel approach: A custom, minimal Linux kernel and KMS application are combined into a single binary, reducing attack surface.
- Remote attestation: TPM features allow verification that only authorized KMS applications are running in an approved state.
- Encrypted master key: The KMS master key is shared across instances but only decryptable by authorized systems using their identity key.
- Hardware isolation: Use of dedicated hardware with disabled remote management functionality enhances security.
- RAM encryption and secure boot further protect against unauthorized access or modifications.
- Process isolation: The central Signer process has no direct network access and only communicates through a Message Bridge, minimizing potential attack vectors.
- Ephemeral key handling: User private keys are only decrypted in memory for the duration of signature calculation, then immediately overwritten, reducing exposure to potential memory-based attacks.

Finally, security is further strengthened via withdraws requiring 2FA, or passkey. Additionally, a set of wasm modules the users authorize are called to validate any transaction the user submits before signing. This prevents any hacker from making unathorized transactions if they are able to access the user's telegram account.

## Wasm Modules
In order to enhance security, only certain transaction types and signatures are approved by the user ahead of time. These approvals are tied to what we call a "Constraint".

### Overview
A Constraint may have multiple properties tied to it. Some examples:

Max_fee
Max_priority_fee
Max_jito_fee
Destination_Address
Max_sol
Mint

A constraint is approved for each transaction type. An example of a transaction type may be a bonkbot Jupiter swap, Withdraw, or an Orca Swap. Each transaction type's shape and set of instructions are defined ahead of time. The wasm modules then makes sure the shape is as defined (no added instructions), any `Transfer`, `Swap` or even a `CreateIdempotent` instruction will only output to the user's address or a PDA derived from the user's address.

Additionally, we have a new fee contract (defined in this scope), that wraps a swap transaction and verifies a positive balance delta for the user. It then transfers a fee defined by the Constraint (Max fee percentage) and to a list of addresses or derivatives of those addresses owned by bonkbot to receive a fee. This ensures no one who gains access to a bonkbot fee address will be able to use this address as a means to drain user funds.

Verification also happens on a max priority fee to the miner and also to specific addresses and max jito fees for jito protection.

The user manages multiple wallets and the keys are rotated to different indexes on the HD standard. In many cases these wallets can be abstracted and constraints can be applied to the summation of wallets that users own. Additionally, validation can be reduced on transfers between the user's different wallets as opposed to withdraws.

Some additional points:
- The wasm modules only communicate with the signer via linear memory, so it is completely isolated.
- Pubkeys for the transaction, constraints, and unsigned transactions are passed via calls via the host runtime on the signer and the source wasm module
- The wasm modules are currently written in Rust, but this framework allows for flexiblity when doing multichain. A module, for example, could be written in GO to target go-ethereum

### Modules

This list of initial modules:

sendsol
sendsol_own
solswap_jupiter
solswap_orca
solswap_meteora
solswap_meteora_dlmm
pumpfun
raydium
raydium_cpmm
moonshot

Each version of the module is hashed and requires user authorization. Another way to think of the modules is:
- The module is a smart contract that executes in under 2ms that the user deploys to their wallet
- When validated by a module, the transaction can be programmatically executed (even similar to a mempool that queues transactions waiting to be validated)
- It can also be considered a form of account abstraction, at least the validation side of AA
- The logic can be time based and a set of constraints can be thought of as an Intent that can be later executed

### Audit Scope
Currently, we can break up the audit into 5 different components:

1. Code that interfaces with the wasm host runtime. This is wire code, and source runtimes. It can do a lookup to the host or send a result to the host.
2. There is boilerplate that is generally shared. PDA generation, utility functions, etc..
3. There is deserialisation code, this is essentially deserialising instructions. For an exchange this could be utilising a CPI or in a lot of the cases just manually grabbing the bytes, deserializing, decoding and extracting data and identifiers.
4. There is the actual validation logic on instructions
5. Then there is the shape that combines re-usable 4) pieces to determine validation.

Initially let's break it out into:
1. 450 LOC
2. 150 LOC
3. 100 LOC
4. 350 LOC
5. 120 LOC for withdraw, 350 for one solswap implementation (since most of the code is generalized)

Total: ~1500 LOC

## Fee Contract
This is a very simple program with pre/post instructions to wrap a swap or instruction that results in a positive sol/token increase for an account.

The wrapping instructions make sure a fee percentage is transferred to a fee address on the positive balance increase. Both the fee percentage and fee address are passed to the on chain program. This contract is immutable for safety reasons and has no upgrade path.

This is based on:
https://github.com/jito-foundation/jito-protecc/

### Audit Scope
Total: ~220 LOC