IOP | Term Structure Institutional

Build Commands, Test Commands, and How to Run Them

install denpendencies forge soldeer update

build forge build

test forge test –skip Fork

Previous Audits

• Term Structure Institutional’s has no audit report as of 28 May 2025.

Where might Security Researchers confuse out-of-scope code to be in-scope?

• Security researchers may incorrectly assume that the collateral management system is within scope because they might question whether collateral that is locked in the lender's wallet can be successfully retrieved during liquidation or repayment events. This confusion arises because the retrieval process is partially controlled by the business logic in the backend, which could lead researchers to believe that the collateral locking and unlocking mechanisms are part of the attackable surface area.

Is this an upgrade of an existing system? If so, which? And what are the main differences?

• No. This is a new product from scratch.

Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?

• We are most concerned about arithmetic overflow and loss of precision issues, which are commonly overlooked in DeFi protocols but can have severe consequences. Given TSI's complex financial calculations, several areas are particularly vulnerable:

What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported?

• ERC20

What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?

• The signer who signs the settlement information is out of scope.

Which chains and/or networks will the code in scope be deployed to?

• Ethereum.

What external dependencies are there?

• Oracles from Chainlink or RedStone. DEXs for liquidation.

Are there any unusual points about your protocol that may confuse Security Researchers?

• All participating addresses use Fireblocks' 2-of-2 Multi-Party Computation (MPC) wallets, where users hold one key share and Fireblocks (not TSI directly) holds the other key share. This creates an unusual custody model that may confuse researchers:

Key Unusual Points:

• Non-Custodial but Coordinated: While TSI never holds user funds directly, the collateral locking mechanism relies on lender pre-approval rather than traditional smart contract escrow. Lenders must pre-sign transactions that allow the settlement smart contract to automatically transfer collateral from their wallet during repayment or liquidation events.

• Hybrid Settlement Model: Unlike typical DeFi protocols where assets are deposited into smart contracts, TSI's settlement contracts facilitate direct wallet-to-wallet transfers. The contracts don't hold funds but coordinate simultaneous exchanges between parties.

• Backend-Triggered Automation: TSI's backend system can trigger certain automated actions (like unlocking collateral during liquidation) because it coordinates with Fireblocks' MPC infrastructure, even though TSI doesn't control the private keys directly.

• Device-Bound Keys: User key shares are bound to specific browsers/devices, making the typical "connect any wallet" assumption invalid.

Researchers might incorrectly assume TSI has direct key control or that smart contracts hold collateral, when in reality the system uses a sophisticated coordination layer between MPC wallets and pre-authorized transaction execution.

What are the most valuable educational resources already available? (Ie. Documentation, Explainer videos or articles, etc)

• [https://docs.institutional.ts.finance/]
• https://www.youtube.com/watch?v=usyhq0ucMOw&list=PLW028xWwhYBHSmzbGLFjd4BybCTrBdjaE