Organization Account and Wallet
Last updated
Last updated
The chart of organization account, wallet and user:
The organization account is the highest-level entity within TSI, representing an institution participating in the platform. An organization must first be created within the TSI system. This account acts as a container for wallets and users associated with that institution.
Wallets within TSI are used to hold and manage digital assets. The above chart shows two example wallets (Wallet A and Wallet B) associated with an organization. Key characteristics of wallets include:
Association with Organizations: Wallets are created and managed within the context of an organization account.
Asset Holding: Each wallet holds a variety of digital assets.
Unique Network-Token Addresses: Each network-token within a wallet has a unique address, ensuring proper tracking and management of assets across different blockchains. The network-token addresses are built automatically when a wallet is created.
The TSI Admin is responsible for the overall management and maintenance of the TSI system. Their key responsibilities include:
Organization Creation: The TSI Admin creates new organization accounts within the system.
Admin Invitation: The TSI Admin invites individuals to become Organization Admins for specific organizations.
The Organization Admin manages the users and wallets within their respective organization. Their key responsibilities include:
Wallet Creation: The Organization Admin creates wallets under their organization's account.
Wallet Assignment: The Organization Admin assigns users to those wallets, granting them appropriate access.
MPC Key Share #2: Similar to users, the Organization Admin also possesses a unique MPC key share (#2) for co-signing transactions related to their administrative duties.
Whitelist Wallets Management: The Organization Admin can create and delete whitelist wallets. The assets in all of the organizational wallets can only be withdrawn to the whitelisted wallets. After the Organization Admin creates a whitelist wallet, the TSI side will confirm the operation with the client and approve the operation, ensuring security and minimizing risk.
Withdrawal: An Organization Admin can withdraw assets from any wallets to any of the whitelist wallets.
Users are individuals who interact with the TSI platform on behalf of an organization. Users are Traders or Trader Viewer.
Trader:
Functionality: Traders can place both borrowing and lending orders within TSI, sign related transactions, manage loans and collaterals.
Wallets: The Organization Admin can associate specific wallets to each trader. A trader can only place orders from the associated wallets.
Withdrawal: Traders can withdraw assets from the associated wallets to any whitelist wallets.
MPC Key Share #2: Each Trader possesses a unique MPC key share (#2), used in conjunction with Fireblocks' key share (#1) to co-sign transactions.
Trader Viewer:
Functionality: Trader Viewers cannot perform any actions in the TSI system. They can only view information like wallet balances, order statuses, transaction statuses, market order books, etc.
Wallets: The Organization Admin can associate specific wallets to each Trader Viewer. A Trader Viewer can only view the associated wallets' information.
A new organization is created within the TSI system by the TSI Admin.
The TSI Admin invites an individual to become the Organization Admin for that organization.
The Organization Admin creates wallets and users under the organization's account.
The Organization Admin assigns users to those wallets, granting them access to manage the assets within the wallets.
MPC Key Generation and Use: Both users and the Organization Admin own and securely store their unique MPC key share (#2). This key share is generated the first time the user or admin signs in to TSI and is securely stored within their device's browser. Each encrypted key share is unique and stored only on the user's or admin's own device. When a transaction is initiated, this key share is used in conjunction with Fireblocks' key share (#1) to create a valid transaction signature. This 2-of-2 MPC scheme ensures that both the user/admin and Fireblocks must participate in signing the transaction, preventing unauthorized access and enhancing security.