Skip to content

Commit

Permalink
docs: DESIGN.md typo fix
Browse files Browse the repository at this point in the history
  • Loading branch information
ahramy committed Aug 12, 2024
1 parent f473eaf commit c259124
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion DESIGN.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ The main workflow of a bridge is as follows:

For the bridge to function effectively, it should be capable of executing these steps between any two supported chains, designated as 'Chain A' and 'Chain B'. There are multiple different possible configurations for any such bridge. Our goal is to make bridging as easy as possible for deployers to get what they want, while also making it cheap and easy for users to transfer their tokens between chains.

The workflow described below is facilitated by 2 smart contracts the [`InterchainTokenService`](./contracts/interchainTokenService/InterchainTokenService.sol) and the [`InterchainTokenFactory`](./contracts/InterchainTokenFactory.sol). The `InterchainTokenService` deploys `TokenManagers` which register each token and is also responsible for sending and receiving messages. Each bridge will result in a new `TokenManager` with a unique `interchainTokenId`. Deployers have a few different options when creating `TokenManagers`, with each option representing a different `TokenManager` type with distinct qualities. The `InterchainTokenFactory` allows developers to deploy bridges that have certain guarantees, such as fixed supply tokens, or bridging pre-existing tokens.
The workflow described below is facilitated by 2 smart contracts the [`InterchainTokenService`](./contracts/InterchainTokenService.sol) and the [`InterchainTokenFactory`](./contracts/InterchainTokenFactory.sol). The `InterchainTokenService` deploys `TokenManagers` which register each token and is also responsible for sending and receiving messages. Each bridge will result in a new `TokenManager` with a unique `interchainTokenId`. Deployers have a few different options when creating `TokenManagers`, with each option representing a different `TokenManager` type with distinct qualities. The `InterchainTokenFactory` allows developers to deploy bridges that have certain guarantees, such as fixed supply tokens, or bridging pre-existing tokens.

It is important to note that a lot of the design choices were made with supporting non-EVM chains in mind.

Expand Down

0 comments on commit c259124

Please sign in to comment.