You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
update dependencies and use example token instead of flow token (#20)
* updating dependencies and using example token instead of flow token
* updating dependencies
* fixing README and example transactions
* using better string templating
* go mod tidy
* make generate contracts
Copy file name to clipboardExpand all lines: README.md
+20-13Lines changed: 20 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -45,9 +45,12 @@ The feedback we are looking for is:
45
45
46
46
## Basics of the Standard:
47
47
48
-
The code for the standard is in `src/contracts/FungibleToken.cdc`. An example implementation of the standard that simulates what a simple FlowToken would be like is in `src/contracts/FlowToken.cdc`.
48
+
The code for the standard is in `src/contracts/FungibleToken.cdc`. An example implementation of the standard that simulates what a simple token would be like is in `src/contracts/ExampleToken.cdc`.
49
+
50
+
The exact smart contract that is used for the official Flow Network Token is in `src/contracts/FlowToken.cdc`
49
51
50
52
Example transactions that users could use to interact with fungible tokens are located in the `src/transactions/` directory.
53
+
Go transaction templates are in the `test/templates.go` file. These templates are mostly generic and can be used with any fungible token implementation by providing the correct addresses, names, and values.
51
54
52
55
The standard consists of a contract interface called `FungibleToken` that requires implementing contracts to define a `Vault` resource that represents the tokens that an account owns. Each account that owns tokens will have a `Vault` stored in its account storage. Users call functions on each other's `Vault`s to send and receive tokens.
53
56
@@ -60,7 +63,7 @@ Right now we are using unsigned 64-bit fixed point numbers `UFix64` as the type
60
63
-`pub var totalSupply: UFix64`
61
64
- The only required field of the contract. It would be incremented when new tokens are minted and decremented when they are destroyed.
62
65
- Event that gets emitted when the contract is initialized
4 - Depositing a specific amount of tokens *from* using the *deposit* function of the recipient's `Vault`
87
90
88
91
-`Receiver` interface
89
-
-`pub fun deposit(from: @Vault)`
92
+
-`pub fun deposit(from: @FungibleToken.Vault)`
90
93
- Conditions
91
94
-`from` balance must be non-zero
92
95
- The resulting balance must be equal to the initial balance + the balance of `from`
93
96
- deposit event
94
97
- Indicates how much was deposited and to what account the `Vault` is stored in.
95
98
If the `Vault` is not in account storage when the event is emitted,
96
99
`to` will be `nil`.
97
-
-`pub event Deposit(amount: UFix64, to: Address?)`
98
-
- Users could create custom `Receiver`s to trigger special code when transfers to them happen.
100
+
-`pub event TokensDeposited(amount: UFix64, to: Address?)`
101
+
- Users could create custom `Receiver`s to trigger special code when transfers to them happen, like forwarding the tokens
102
+
to another account, splitting them up, and much more.
103
+
104
+
-**ATTENTION**: It is VITALLY important that if you are making your own implementation of the fungible token interface that
105
+
you cast the input to `deposit` as the type of your token.
106
+
`let vault <- from as! @ExampleToken.Vault`
107
+
Because the interface specifies the argument as `@FungibleToken.Vault`, any resource that satisfies this can be sent to the deposit function. If you do not cast it as the type of your token, others could deposit different tokens into your Vault maliciously to change the balance.
99
108
100
109
5 - Creating an empty Vault resource
101
110
102
-
-`pub fun createEmptyVault(): @Vault`
103
-
- Currently have no event
104
-
- Defined in the contract, but not in the `Vault` resource.
105
-
This means that to create an empty `Vault`,
106
-
the caller would always have to call the function in the contract.
111
+
-`pub fun createEmptyVault(): @FungibleToken.Vault`
112
+
- Defined in the contract
113
+
To create an empty `Vault`, the caller calls the function in the contract and stores the Vault in their storage.
107
114
- Conditions:
108
115
- the balance of the returned Vault must be 0
109
116
@@ -173,7 +180,7 @@ A standard for token metadata is still an unsolved problem in the general blockc
173
180
To use the Flow Token contract as is, you need to follow these steps:
174
181
175
182
1. Deploy the `FungibleToken` definition to account `0x02`
176
-
2. Deploy the `FlowToken` definition to account `0x03`
183
+
2. Deploy the `ExampleToken` definition to account `0x03`
177
184
3. You can use the `get_balance.cdc` or `get_supply.cdc` scripts to read the
178
185
balance of a user's `Vault` or the total supply of all tokens, respectively.
179
186
4. Use the `setupAccount.cdc` on any account to set up the account to be able to
0 commit comments