New translations upgrading-a-subgraph.mdx (Korean)

website/pages/ko/cookbook/upgrading-a-subgraph.mdx

@@ -10,10 +10,10 @@ The process of upgrading is quick and your subgraphs will forever benefit from t
 
 ### Prerequisites
 
-- You have already deployed a subgraph on the hosted service.
-- The subgraph is indexing a chain available on The Graph Network.
-- You have a wallet with ETH to publish your subgraph on-chain.
-- You have ~10,000 GRT to curate your subgraph so Indexers can begin indexing it.
+-   You have already deployed a subgraph on the hosted service.
+-   The subgraph is indexing a chain available on The Graph Network.
+-   You have a wallet with ETH to publish your subgraph on-chain.
+-   You have ~10,000 GRT to curate your subgraph so Indexers can begin indexing it.
 
 ## Upgrading an Existing Subgraph to The Graph Network
 
@@ -70,9 +70,9 @@ graph deploy --studio <SUBGRAPH_SLUG>
 
 6.  At this point, your subgraph is now deployed on Subgraph Studio, but not yet published to the decentralized network. You can now test the subgraph to make sure it is working as intended using the temporary query URL as seen on top of the right column above. As this name already suggests, this is a temporary URL and should not be used in production.
 
-- Updating is just publishing another version of your existing subgraph on-chain.
-- Because this incurs a cost, it is highly recommended to deploy and test your subgraph in the Subgraph Studio, using the "Development Query URL" before publishing. See an example transaction [here](https://etherscan.io/tx/0xd0c3fa0bc035703c9ba1ce40c1862559b9c5b6ea1198b3320871d535aa0de87b). Prices are roughly around 0.0425 ETH at 100 gwei.
-- Any time you need to update your subgraph, you will be charged an update fee. Because this incurs a cost, it is highly recommended to deploy and test your subgraph on Goerli before deploying to mainnet. It can, in some cases, also require some GRT if there is no signal on that subgraph. In the case there is signal/curation on that subgraph version (using auto-migrate), the taxes will be split.
+-   Updating is just publishing another version of your existing subgraph on-chain.
+-   Because this incurs a cost, it is highly recommended to deploy and test your subgraph in the Subgraph Studio, using the "Development Query URL" before publishing. See an example transaction [here](https://etherscan.io/tx/0xd0c3fa0bc035703c9ba1ce40c1862559b9c5b6ea1198b3320871d535aa0de87b). Prices are roughly around 0.0425 ETH at 100 gwei.
+-   Any time you need to update your subgraph, you will be charged an update fee. Because this incurs a cost, it is highly recommended to deploy and test your subgraph on Goerli before deploying to mainnet. It can, in some cases, also require some GRT if there is no signal on that subgraph. In the case there is signal/curation on that subgraph version (using auto-migrate), the taxes will be split.
 
 7.  Publish the subgraph on The Graph's decentralized network by hitting the "Publish" button.
 
@@ -90,14 +90,14 @@ You can generate an API key in Subgraph Studio [here](https://thegraph.com/studi
 
 At the end of each week, an invoice will be generated based on the query fees that have been incurred during this period. This invoice will be paid automatically using the GRT available in your balance. Your balance will be updated after the cost of your query fees are withdrawn. Query fees are paid in GRT via the Arbitrum network. You will need to add GRT to the Arbitrum billing contract to enable your API key via the following steps:
 
-- Purchase GRT on an exchange of your choice.
-- Send the GRT to your wallet.
-- On the Billing page in Studio, click on Add GRT.
+-   Purchase GRT on an exchange of your choice.
+-   Send the GRT to your wallet.
+-   On the Billing page in Studio, click on Add GRT.
 
 ![Add GRT in billing](/img/Add-GRT-New-Page.png)
 
-- Follow the steps to add your GRT to your billing balance.
-- Your GRT will be automatically bridged to the Arbitrum network and added to your billing balance.
+-   Follow the steps to add your GRT to your billing balance.
+-   Your GRT will be automatically bridged to the Arbitrum network and added to your billing balance.
 
 ![Billing pane](/img/New-Billing-Pane.png)
 
@@ -158,17 +158,17 @@ graph deploy --studio <SUBGRAPH_SLUG>
 
 ### Owner Update Fee: Deep Dive
 
-> Note: Curation on Arbitrum does not use bonding curves. Learn more about Arbitrum [here](/arbitrum/arbitrum-faq/).
+> Note: Curation on Arbitrum has a flat bonding curve. Learn more about Arbitrum [here](/arbitrum/arbitrum-faq/).
 
 An update requires GRT to be migrated from the old version of the subgraph to the new version. This means that for every update, a new bonding curve will be created (more on bonding curves [here](/network/curating#bonding-curve-101)).
 
 The new bonding curve charges the 1% curation tax on all GRT being migrated to the new version. The owner must pay 50% of this or 1.25%. The other 1.25% is absorbed by all the curators as a fee. This incentive design is in place to prevent an owner of a subgraph from being able to drain all their curator's funds with recursive update calls. If there is no curation activity, you will have to pay a minimum of 100 GRT in order to signal your own subgraph.
 
 Let's make an example, this is only the case if your subgraph is being actively curated on:
 
-- 100,000 GRT is signaled using auto-migrate on v1 of a subgraph
-- Owner updates to v2. 100,000 GRT is migrated to a new bonding curve, where 97,500 GRT get put into the new curve and 2,500 GRT is burned
-- The owner then has 1250 GRT burned to pay for half the fee. The owner must have this in their wallet before the update, otherwise, the update will not succeed. This happens in the same transaction as the update.
+-   100,000 GRT is signaled using auto-migrate on v1 of a subgraph
+-   Owner updates to v2. 100,000 GRT is migrated to a new bonding curve, where 97,500 GRT get put into the new curve and 2,500 GRT is burned
+-   The owner then has 1250 GRT burned to pay for half the fee. The owner must have this in their wallet before the update, otherwise, the update will not succeed. This happens in the same transaction as the update.
 
 _While this mechanism is currently live on the network, the community is currently discussing ways to reduce the cost of updates for subgraph developers._
 
@@ -188,8 +188,8 @@ Make sure **Update Subgraph Details in Explorer** is checked and click on **Save
 
 1.  Leveraging an ENS name for Subgraph Development:
 
-- Set up your ENS [here](https://app.ens.domains/)
-- Add your ENS name to your settings [here](https://thegraph.com/explorer/settings?view=display-name).
+-   Set up your ENS [here](https://app.ens.domains/)
+-   Add your ENS name to your settings [here](https://thegraph.com/explorer/settings?view=display-name).
 
 2.  The more filled out your profiles are, the better the chances for your subgraphs to be indexed and curated.
 
@@ -219,7 +219,7 @@ If you're still confused, fear not! Check out the following resources or watch o
 
 <VideoEmbed youtube="CzdQ3dFFrjo" />
 
-- [The Graph Network Contracts](https://github.com/graphprotocol/contracts)
-- [Curation Contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - the underlying contract that the GNS wraps around
-  - Address - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538`
-- [Subgraph Studio documentation](/deploying/subgraph-studio)
+-   [The Graph Network Contracts](https://github.com/graphprotocol/contracts)
+-   [Curation Contract](https://github.com/graphprotocol/contracts/blob/dev/contracts/curation/Curation.sol) - the underlying contract that the GNS wraps around
+    -   Address - `0x8fe00a685bcb3b2cc296ff6ffeab10aca4ce1538`
+-   [Subgraph Studio documentation](/deploying/subgraph-studio)