refactor: final token naming cleanup

docs/docs/guides/developer_guides/getting_started.md

@@ -139,12 +139,12 @@ In the next step, let's mint some tokens!
 Call the public mint function like this:
 
 ```bash
-aztec-wallet send mint_public --from accounts:my-wallet --contract-address contracts:testtoken --args accounts:my-wallet 100
+aztec-wallet send mint_to_public --from accounts:my-wallet --contract-address contracts:testtoken --args accounts:my-wallet 100
 ```
 
 This takes
 
-- the function name as the argument, which is `mint_public`
+- the function name as the argument, which is `mint_to_public`
 - the `from` account (caller) which is `accounts:my-wallet`
 - the contract address, which is aliased as `contracts:testtoken` (or simply `testtoken`)
 - the args that the function takes, which is the account to mint the tokens into (`my-wallet`), and `amount` (`100`).
@@ -165,7 +165,7 @@ Transaction has been mined
  Status: success
  Block number: 17
  Block hash: 1e27d200600bc45ab94d467c230490808d1e7d64f5ee6cee5e94a08ee9580809
-Transaction hash stored in database with aliases last & mint_public-9044
+Transaction hash stored in database with aliases last & mint_to_public-9044
 ```
 
 You can double-check by calling the function that checks your public account balance:

docs/docs/guides/developer_guides/js_apps/authwit.md

@@ -68,9 +68,9 @@ Then create the message hash by hashing the inner hash with the authwit receiver
 
 ## Create the authwit
 
-There are slightly different interfaces depending on whether your contract is checking the authwit in private or public. 
+There are slightly different interfaces depending on whether your contract is checking the authwit in private or public.
 
-Public authwits are stored in the account contract and batched with the authwit action call, so a user must send a transaction to update their account contract, authorizing an action before the authorized contract's public call will succeed. 
+Public authwits are stored in the account contract and batched with the authwit action call, so a user must send a transaction to update their account contract, authorizing an action before the authorized contract's public call will succeed.
 
 Private execution uses oracles and are executed locally by the PXE, so the authwit needs to be created by the authwit giver and then added to the authwit receiver's PXE.
 
@@ -107,7 +107,7 @@ Set a public authwit like this:
 Remember it is a transaction and calls a method in the account contract. In this example,
 
 - `wallets[0]` is the authwit giver
-- `wallets[1]` is the authwit reciever and caller of the function
+- `wallets[1]` is the authwit receiver and caller of the function
 - `action` was [defined previously](#define-the-action)
 - `true` sets the `authorized` boolean (`false` would revoke this authwit)
 

docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md

@@ -199,8 +199,8 @@ export class TokenContract extends ContractBase {
 
   /** Type-safe wrappers for the public methods exposed by the contract. */
   public override methods!: {
-    /** transfer_public(from: struct, to: struct, amount: field, nonce: field) */
-    transfer_public: ((
+    /** transfer_in_public(from: struct, to: struct, amount: field, nonce: field) */
+    transfer_in_public: ((
       from: AztecAddressLike,
       to: AztecAddressLike,
       amount: FieldLike,

docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md

@@ -118,13 +118,13 @@ Our test environment is capable of utilizing the autogenerated contract interfac
 
 For example, to call the private `transfer` function on the token contract:
 
-#include_code txe_test_transfer_private /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code txe_test_transfer_private /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer.nr rust
 
 #### Public
 
-To call the public `transfer_public` function:
+To call the public `transfer_in_public` function:
 
-#include_code call_public /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_public.nr rust
+#include_code call_public /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr rust
 
 #### Unconstrained
 
@@ -178,11 +178,11 @@ Reading notes:
 
 You can add [authwits](../writing_contracts/authwit.md) to the TXE. Here is an example of testing a private token transfer using authwits:
 
-#include_code private_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code private_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr rust
 
 #### Public
 
-#include_code public_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_public.nr rust
+#include_code public_authwit /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr rust
 
 ### Storing notes in cache
 
@@ -206,7 +206,7 @@ You can test functions that you expect to fail generically, with the `#[test(sho
 
 For example:
 
-#include_code fail_with_message /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_private.nr rust
+#include_code fail_with_message /noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr rust
 
 You can also use the `assert_public_call_fails` or `assert_private_call_fails` methods on the `TestEnvironment` to check that a call fails.
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md

@@ -141,7 +141,7 @@ Then you will be able to import it into your contracts as follows.
 
 Based on the diagram earlier on this page let's take a look at how we can implement the `transfer` function such that it checks if the tokens are to be transferred `from` the caller or needs to be authenticated with an authentication witness.
 
-#include_code transfer_from /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
+#include_code transfer_in_private /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
 The first thing we see in the snippet above, is that if `from` is not the call we are calling the `assert_current_call_valid_authwit` function from [earlier](#private-functions). If the call is not throwing, we are all good and can continue with the transfer.
 
@@ -151,7 +151,7 @@ In the snippet we are constraining the `else` case such that only `nonce = 0` is
 
 Cool, so we have a function that checks if the current call is authenticated, but how do we actually authenticate it? Well, assuming that we use a wallet that is following the spec, we import `computeAuthWitMessageHash` from `aztec.js` to help us compute the hash, and then we simply `addAuthWitness` to the wallet. Behind the scenes this will make the witness available to the oracle.
 
-#include_code authwit_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_private.test.ts typescript
+#include_code authwit_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_private.test.ts typescript
 
 Learn more about authwits in Aztec.js by [following this guide](../../js_apps/authwit.md).
 
@@ -161,15 +161,15 @@ With private functions covered, how can we use this in a public function? Well,
 
 #### Checking if the current call is authenticated
 
-#include_code transfer_public /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
+#include_code transfer_in_public /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
 #### Authenticating an action in TypeScript
 
 Authenticating an action in the public domain is slightly different from the private domain, since we are executing a function on the auth registry contract to add the witness flag. As you might recall, this was to ensure that we don't need to call into the account contract from public, which is a potential DOS vector.
 
 In the snippet below, this is done as a separate contract call, but can also be done as part of a batch as mentioned in the [Accounts concepts](../../../../aztec/concepts/accounts/authwit.md#what-about-public).
 
-#include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_public.test.ts typescript
+#include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts typescript
 
 #### Updating approval state in Noir
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md

@@ -21,7 +21,7 @@ We call this the "authentication witness" pattern or authwit for short.
 Here you approve a contract to burn funds on your behalf.
 
 - Approve in public domain:
-  #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_public.test.ts typescript
+  #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts typescript
 
 Here you approve someone to transfer funds publicly on your behalf
 
@@ -84,8 +84,6 @@ Let's say you have some storage in public and want to move them into the private
 
 So you have to create a custom note in the public domain that is not encrypted by some owner - we call such notes a "TransparentNote" since it is created in public, anyone can see the amount and the note is not encrypted by some owner.
 
-This pattern is discussed in detail in [the codealong token tutorial in the shield() method](../../../../../tutorials/codealong/contract_tutorials/token_contract.md#redeem_shield).
-
 ### Discovering my notes
 
 When you send someone a note, the note hash gets added to the note hash tree. To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes:

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md

@@ -53,7 +53,7 @@ The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Azt
 
 ### Token portal hash library
 
-#include_code mint_public_content_hash_nr /noir-projects/noir-contracts/contracts/token_portal_content_hash_lib/src/lib.nr rust
+#include_code mint_to_public_content_hash_nr /noir-projects/noir-contracts/contracts/token_portal_content_hash_lib/src/lib.nr rust
 
 ### Token Portal contract
 

docs/docs/reference/developer_references/sandbox_reference/cli_wallet_reference.md

@@ -104,10 +104,10 @@ The authwit management in private is a two-step process: create and add. It's no
 
 #### Example
 
-An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_from action (transfer on the user's behalf):
+An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_in_private action (transfer on the user's behalf):
 
 ```bash
-aztec-wallet create-authwit transfer_from accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
+aztec-wallet create-authwit transfer_in_private accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
 
 aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:coruscant_trader
 ```
@@ -117,7 +117,7 @@ aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:
 A similar call to the above, but in public:
 
 ```bash
-aztec-wallet authorize-action transfer_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
+aztec-wallet authorize-action transfer_in_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
 ```
 
 ### Simulate

docs/docs/tutorials/codealong/cli_wallet/faceid_wallet.md

@@ -103,9 +103,9 @@ You should get a prompt to sign this transaction. You can now mint, transfer, an
 
 ```bash
 aztec-wallet create-account -a new_recipient # creating a schnorr account
-aztec-wallet send mint_public -ca last --args accounts:my-wallet 10 -f accounts:my-wallet # minting some tokens in public
+aztec-wallet send mint_to_public -ca last --args accounts:my-wallet 10 -f accounts:my-wallet # minting some tokens in public
 aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:my-wallet -f my-wallet # checking that my-wallet has 10 tokens
-aztec-wallet send transfer_public -ca contracts:devtoken --args accounts:my-wallet accounts:new_recipient 10 0 -f accounts:my-wallet # transferring some tokens in public
+aztec-wallet send transfer_in_public -ca contracts:devtoken --args accounts:my-wallet accounts:new_recipient 10 0 -f accounts:my-wallet # transferring some tokens in public
 aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:new_recipient -f my-wallet # checking that new_recipient has 10 tokens
 ```
 

docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md

@@ -57,7 +57,7 @@ Here is an explanation of what it is doing:
    - The content is limited to a single field (~254 bits). So if the content is larger, we have to hash it and the hash can be passed along.
      - We use our utility method that creates a sha256 hash but truncates it to fit into a field
    - Since we want to mint tokens on Aztec publicly, the content here is the amount to mint and the address on Aztec who will receive the tokens.
-   - We encode this message as a mint_public function call, to specify the exact intentions and parameters we want to execute on L2.
+   - We encode this message as a mint_to_public function call, to specify the exact intentions and parameters we want to execute on L2.
      - In reality the content can be constructed in any manner as long as the sister contract on L2 can also create it. But for clarity, we are constructing the content like an ABI encoded function call.
      - It is good practice to include all parameters used by L2 into this content (like the amount and to) so that a malicious actor can’t change the to to themselves when consuming the message.
 3. The tokens are transferred from the user to the portal using `underlying.safeTransferFrom()`. This puts the funds under the portal's control.

docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md

@@ -28,15 +28,15 @@ The `claim_public` function enables anyone to consume the message on the user's
 
 **What’s happening here?**
 
-1. We first recompute the L1->L2 message content by calling `get_mint_public_content_hash()`. Note that the method does exactly the same as what the TokenPortal contract does in `depositToAztecPublic()` to create the content hash.
+1. We first recompute the L1->L2 message content by calling `get_mint_to_public_content_hash()`. Note that the method does exactly the same as what the TokenPortal contract does in `depositToAztecPublic()` to create the content hash.
 2. We then attempt to consume the L1->L2 message. Since we are depositing to Aztec publicly, all of the inputs are public.
    - `context.consume_l1_to_l2_message()` takes in the few parameters:
-     - `content_hash`: The content - which is reconstructed in the `get_mint_public_content_hash()`
+     - `content_hash`: The content - which is reconstructed in the `get_mint_to_public_content_hash()`
      - `secret`: The secret used for consumption, often 0 for public messages
      - `sender`: Who on L1 sent the message. Which should match the stored `portal_address` in our case as we only want to allow messages from a specific sender.
      - `message_leaf_index`: The index in the message tree of the message.
    - Note that the `content_hash` requires `to` and `amount`. If a malicious user tries to mint tokens to their address by changing the to address, the content hash will be different to what the token portal had calculated on L1 and thus not be in the tree, failing the consumption. This is why we add these parameters into the content.
-3. Then we call `Token::at(storage.token.read()).mint_public()` to mint the tokens to the to address.
+3. Then we call `Token::at(storage.token.read()).mint_to_public()` to mint the tokens to the to address.
 
 ## Private flow
 
@@ -48,7 +48,7 @@ Now we will create a function to mint the amount privately. Paste this into your
 
 The `get_mint_private_content_hash` function is imported from the `token_portal_content_hash_lib`.
 
-If the content hashes were constructed similarly for `mint_private` and `mint_publicly`, then content intended for private execution could have been consumed by calling the `claim_public` method. By making these two content hashes distinct, we prevent this scenario.
+If the content hashes were constructed similarly for `mint_private` and `mint_to_publicly`, then content intended for private execution could have been consumed by calling the `claim_public` method. By making these two content hashes distinct, we prevent this scenario.
 
 While we mint the tokens on L2, we _still don’t actually mint them to a certain address_. Instead we continue to pass the `secret_hash_for_redeeming_minted_notes` like we did on L1. This means that a user could reveal their secret for L2 message consumption for anyone to mint tokens on L2 but they can redeem these notes at a later time. **This enables a paradigm where an app can manage user’s secrets for L2 message consumption on their behalf**. **The app or any external party can also mint tokens on the user’s behalf should they be comfortable with leaking the secret for L2 Message consumption.** This doesn’t leak any new information to the app because their smart contract on L1 knew that a user wanted to move some amount of tokens to L2. The app still doesn’t know which address on L2 the user wants these notes to be in, but they can mint tokens nevertheless on their behalf.