Manager Contracts

The Manager Contracts are the main entry points to the Frictionless protocol, they perform market functions such as permission management, treasury operations, issuance, transfer and settlement of securities, and attestations of deposits (proof-of-reserve) for the underlying of FrictionlessFundDepositTokens.

There are four main manager contracts in the Frictionless protocol, as described below.

• FrictionlessPermissionsManager

• FrictionlessTransferManager

• FrictionlessTreasuryManager

• FrictionlessAttestationManager

FrictionlessPermissionsManager

The FrictionlessPermissionsManager defines a set of functions and events related to managing participants' permissions in the Frictionless protocol.

The interface includes an enumeration FrictionlessPermissionedUser that enumerates different participants in the Frictionless protocol, such as PROTOCOL_TREASURY, PERMISSIONED_CUSTODIAN, etc.

Only valid agents can register, add or remove users and their associated claims.

FrictionlessTransferManager

The FrictionlessTransferManager manages the transfer of tokens within the Frictionless protocol. It is also responsible for the collection of fees associated with the exchange of tokens. These fees are mapped to specific fee schedules set by managers on their respective issuances.

The FrictionlessTransferManager overview is provided in the source README.

The Frictionless protocol enables GPs and Managers to collect fees on the primary issuance and secondary trades of digital securities.

The Frictionless protocol enables Investors to bilaterally trade digital securities via the FrictionlessTransferManager smart contract whilst enabling Managers to optionally collect fees on the transaction.

SeeonlyCounterpart mode

The Frictionless protocol enables Managers and GPs to control cash distributions, waterfalls, and capital calls without the direct action of Investors, enabling sophisticated automation via the Frictionless Markets APIs and Manager automation interface.

See onlyTreasury mode

onlyTreasury Mode

exchangeTokens , this function will execute the exchange of tokens between two counterparties, but it is executed by the PROTOCOL_TREASURY as the transfer agent optionally collecting fees. For example, payment in FrictionlessFundDepositToken by an Investor for FricitonlessDigitalSecurityToken held by a custodian (Primary trade) or FricitonlessDigitalSecurityToken held by another Investor (secondary trade).

Schematic of Frictionless transfer of tokens by the PROTOCOL_TREASURY

The exchange flow is as follows:

1. The PROTOCOL_ADMIN optionally sets the transfer fees for the token inbound and outbound.

2. The PROTOCOL_TREASURY invokes the exchangeTokens function, indicating the polarity of the transaction, such as cash for cash, cash for security, security for cash, or security for security. There are many options, but they all result in the same outcome, the compliant transfer of a Frictionless token for another Frictionless token in a single atomic transaction on-chain.

3. The transfer is enacted using the ERC-3643-compliant token transfer IToken.forcedTransfer.

More scenarios for DvP are described in the source README.

onlyCounterpart Mode

createTransferOffer confirmTransferOffer, cancelTransferOffer these functions will execute the exchange tokens in a bilateral P2P mode between two counterparties in a maker-taker mode. This mode also optionally enables the protocol to collect fees.

Schematic of Frictionless transfer of tokens bilaterally by Investors

The exchange flow is as follows:

1. The PROTOCOL_ADMIN optionally sets the transfer fees for the token inbound and outbound.

2. Investor X invokes the createTransferOffer function, indicating the offer, such as cash for cash, cash for security, security for cash, or security for security. There are many options, but they all result in the same outcome, the compliant transfer of a Frictionless token for another Frictionless token in a single atomic transaction on-chain.

3. Investor Y can accept the offer by invoking the confirmTransferOffer function, ensuring the ERC-3643-compliant token transfer using IToken.transferFrom.

FrictionlessTreasuryManager

The FrictionlessTreasuryManager manages the minting, transfer, and burning of various tokens within the Frictionless protocol

1. Token Minting and Management:

   • The contract provides functions to mint different types of tokens within the Frictionless protocol, including Fund Deposit Tokens (mintFundDepositForTreasury), Digital Security Tokens (mintDigitalSecurity), and On-Chain Asset Tokens (mintOnChainAsset).

   • Tokens are associated with compliance contracts, and their minting is subject to specific conditions, roles, and permissions.

2. Token Transfer and Burning:

   • The contract allows for the transfer and burning of tokens through functions like transferToken and burnToken. These actions are performed by an agent with the necessary permissions.

3. Fund Deposit Token Management:

   • The contract keeps track of existing Fund Deposit Tokens using a mapping _existingFundDepositTokens. It prevents the creation of duplicate Fund Deposit Tokens for the same currency and fund IBAN.

The PROTOCOL_ADMIN is the only role permissioned to initially mint any Frictionless tokens, thereafter valid agents such as the PROTOCOL_TREASURY are permitted to increase supply (mint to address), transfer and burn Frictionless tokens.

FrictionlessAttestationManager

The FrictionlessAttestationManager responsible for providing attestations of the balances held in the underlying funding account for each FrictionlessFundDepositToken. The attestation is provided and signed by an independent 3rd party, known as PERMISSIONED_FUND_ACCOUNTANT in the Frictionless protocol.

Attestations are proof of balances in each currency on a regular basis for example, daily or hourly, the attestation data is based on the following snapshot of the currency account underpinning the FrictionlessFundDepositToken.

ATTESTATION FIELD	ATTESTATION COMMENT
CASH_IBAN	The IBAN of the cash account
CURRENCY	The 3-letter currency code of the cash account
REPORT_START_DATE	The start of this report, for example, yesterday at 6AM
REPORT_END_DATE	The end of this report, for example, today at 6AM
CASH_BALANCE	The actual balance on the account as of REPORT_END_DATEfor example, today 6AM
LAST_TX_COUNTERPARTY_ID	The ID of the counterparty in the last transaction on the account
LAST_TX_TIMESTAMP	The timestamp (same format as REPORT_END_DATE) in the last transaction on the account
LAST_TX_AMOUNT	The amount of the the last transaction on the account, A credit transaction is positive and a debit transaction is negative

The attestation workflows are described in the source README.