Replace ethereum/sourcify with argotorg/sourcify

kuzdogan · kuzdogan · commit 111d505bcdfb · 2025-08-28T19:44:10.000+03:00
diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
 # Sourcify Docs
 
-Documentation for [sourcify.eth](https://github.com/ethereum/sourcify).
+Documentation for [sourcify.eth](https://github.com/argotorg/sourcify).
 
 This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
 
diff --git a/blog/apiv2-lookup-endpoints/index.mdx b/blog/apiv2-lookup-endpoints/index.mdx
@@ -17,23 +17,23 @@ In this post we will walkthrough the new functionality brought by these endpoint
 
 ## Background 
 
-APIv2 has been the biggest priority of our project since Q4 2024 and we aim to ship it fully by Q1 2025. We've been discussing and having fruitful conversations around how to design the new API as can be seen in the [design issue](https://github.com/ethereum/sourcify/issues/1545). Thanks everyone who contributed to the conversation!
+APIv2 has been the biggest priority of our project since Q4 2024 and we aim to ship it fully by Q1 2025. We've been discussing and having fruitful conversations around how to design the new API as can be seen in the [design issue](https://github.com/argotorg/sourcify/issues/1545). Thanks everyone who contributed to the conversation!
 
 The main problems we wanted to solve with and the main features we wanted from the APIv2 were the following:
 - With the legacy API users had to wait for the response ie. wait for the compilation and the verification to finish. This can easily take couple minutes and the requests are left hanging. The new design should have ticketing/job-ids and users should poll with this id.
 - The  "perfect" vs "partial" naming is confusing.
 - The legacy API is fully based on the metadata.json. While we want to keep full support for metadata.json verification and "perfect" matching, we wanted to have standard JSON input as our main endpoint's base.
 - We were able to share a lot more data around the verification after moving from a filesystem based storage to [the database](https://docs.sourcify.dev/docs/repository/sourcify-database/) and legacy API didn't have this information.
 
-You can read more in [this issue](https://github.com/ethereum/sourcify/issues/1470).
+You can read more in [this issue](https://github.com/argotorg/sourcify/issues/1470).
 
 (Edit: The design is live [in our docs](https://docs.sourcify.dev/docs/api/))
 
 The design specifies endpoints to "Verify Contracts", check for "Verification Jobs", and to do "Contract Lookup". Here we'll talk about the "Contract Lookup" that we shipped. The others are still being developed.
 
 ## New endpoints
 
-With [this release](https://github.com/ethereum/sourcify/releases/tag/sourcify-server%402.6.0) we have 2 new endpoints:
+With [this release](https://github.com/argotorg/sourcify/releases/tag/sourcify-server%402.6.0) we have 2 new endpoints:
 
 - GET `/v2/contracts/{chainId}`: retrieve the latest verified contracts for a chain
 - GET `/v2/contract/{chainId}/{address}`: retrieve a specific contract and related information
@@ -391,14 +391,14 @@ export type ProxyType =
   | "SequenceWalletProxy";
 ```
 
-See [proxy-utils.ts](https://github.com/ethereum/sourcify/blob/staging/services/server/src/server/services/utils/proxy-contract-util.ts) to see how resolution is done.
+See [proxy-utils.ts](https://github.com/argotorg/sourcify/blob/staging/services/server/src/server/services/utils/proxy-contract-util.ts) to see how resolution is done.
 
 ## Next Steps
 
 As said, this is just the lookup endpoints of the APIv2. In the upcoming weeks we will be developing the verificaiton and verificationJob endpoints that will support ticketing and polling, instead of hanging requests.
 
 Once again, you can see the full up-to-date API spec at https://docs.sourcify.dev/docs/api/
 
-You can follow along the development in our tracker issue: https://github.com/ethereum/sourcify/issues/1367
+You can follow along the development in our tracker issue: https://github.com/argotorg/sourcify/issues/1367
 
 Beyond that, you can see our roadmap in our [Milestones View](https://github.com/orgs/ethereum/projects/46/views/3) for the next quarters and what we are currently working in our [Sprint Board](https://github.com/orgs/ethereum/projects/46/views/2). We welcome feedback and discussions!
diff --git a/blog/roadmap-2025/index.mdx b/blog/roadmap-2025/index.mdx
@@ -61,24 +61,24 @@ Finally, to improve the verification experience we want to:
 
 What we did so far since about 12 months ago:
 - **Shipped APIv2:** Our previous API was inherited from the project's early days and had major issues including no ticketing system causing timeouts, bloated endpoints for different match types, lack of std-json support, and poor error messaging. The new API also uses the new DB which allows us to return rich information about the verification process.
-  - API Design: https://github.com/ethereum/sourcify/issues/1470
-  - Lookup endpoints: https://github.com/ethereum/sourcify/issues/1367
-  - Verify endpoints: https://github.com/ethereum/sourcify/issues/2033
+  - API Design: https://github.com/argotorg/sourcify/issues/1470
+  - Lookup endpoints: https://github.com/argotorg/sourcify/issues/1367
+  - Verify endpoints: https://github.com/argotorg/sourcify/issues/2033
 
-- **Added Vyper support** https://github.com/ethereum/sourcify/issues/1364
+- **Added Vyper support** https://github.com/argotorg/sourcify/issues/1364
 - **Refactored the lib-sourcify** package, which contains the main verification logic, into a more modularized version that reflects the practical verification flow and the mental model. The new package lets you "bring your own compiler". Following that the cloud instance counts reduced by >50%. The process got a lot more efficient and easier to debug.
-    - https://github.com/ethereum/sourcify/issues/1665    
+    - https://github.com/argotorg/sourcify/issues/1665    
 - **Lib-sourcify on browser**: Refactored lib-sourcify to work on browser
-    - https://github.com/ethereum/sourcify/issues/1365
+    - https://github.com/argotorg/sourcify/issues/1365
 - **Unified verification plugin for Remix**: Shipped the "unified verification plugin" for Remix ([tweet](https://x.com/SourcifyEth/status/1849450860600021229))
-    - https://github.com/ethereum/sourcify/issues/1331
+    - https://github.com/argotorg/sourcify/issues/1331
     - Here we lead the example of verifying everywhere and convince frameworks to implement this
 - **Verifier Alliance**: Kicked off and led the Verifier Alliance development: We teamed up with Blockscout and Routescan to create a shared database of verified contracts.
     - https://verifieralliance.org
 - **New verification UI**: Shipped the new verification UI https://verify.sourcify.dev
-    - https://github.com/ethereum/sourcify/issues/1814
+    - https://github.com/argotorg/sourcify/issues/1814
 - **New repo UI**: Shipped the new repo UI (verified contract view) https://repo.sourcify.dev
-    - https://github.com/ethereum/sourcify/issues/1813
+    - https://github.com/argotorg/sourcify/issues/1813
 - **Increased contract coverage**  ([stats here](https://github.com/sourcifyeth/sourcify-stats))
   - Aug 2025: 8.5M contracts (today)
   - Jan 2025: 5.8M contracts
@@ -91,13 +91,13 @@ What we did so far since about 12 months ago:
 We work in 2-week sprints ([sprint board](https://github.com/orgs/ethereum/projects/46/views/2)) and every quarter we have a retrospective and a planning session ([quarterly board](https://github.com/orgs/ethereum/projects/46/views/7)). Our concrete quarterly goals as of today:
 
 <p style={{fontWeight: "bold", marginBottom: "0.1rem"}}>2025 Q3:</p>
-- **4bytes DB**: Recently we observed the need for a comprehensive 4byte signature DB and a well-designed API. We will be building this from our dataset of verified contracts and release it for community use. https://github.com/ethereum/sourcify/issues/2213
-- **Public Queryable DB instance**: We will be shipping a public queryable DB instance. Anyone can query our DB quickly to find contracts, patterns, etc. https://github.com/ethereum/sourcify/issues/2214
+- **4bytes DB**: Recently we observed the need for a comprehensive 4byte signature DB and a well-designed API. We will be building this from our dataset of verified contracts and release it for community use. https://github.com/argotorg/sourcify/issues/2213
+- **Public Queryable DB instance**: We will be shipping a public queryable DB instance. Anyone can query our DB quickly to find contracts, patterns, etc. https://github.com/argotorg/sourcify/issues/2214
 - **Verified Contract Coverage**: Reaching out to chains and potential data sources to increase the verified contract coverage.
-- **Bug fixes and misc**: Smaller tasks we commit to complete https://github.com/ethereum/sourcify/issues/2215
+- **Bug fixes and misc**: Smaller tasks we commit to complete https://github.com/argotorg/sourcify/issues/2215
 
 <p style={{fontWeight: "bold", marginBottom: "0.1rem"}}>2025 Q4:</p>
-- **Bytecode Similarity search**: It should be possible to find similar contracts by bytecode even if they are not verified. https://github.com/ethereum/sourcify/issues/1642
+- **Bytecode Similarity search**: It should be possible to find similar contracts by bytecode even if they are not verified. https://github.com/argotorg/sourcify/issues/1642
 
 <p style={{fontWeight: "bold", marginBottom: "0.1rem"}}>Non-milestone goals:</p>
 - Now that the product is technically sound and ready to scale, boost visibility.
diff --git a/blog/technical-verification-walkthrough/index.mdx b/blog/technical-verification-walkthrough/index.mdx
@@ -59,7 +59,7 @@ User request to Sourcify:
 ```
 
 
-For now the metadata.json is the main way to submit contracts to Sourcify. All other methods such as "Import from Etherscan" all workaround to generate the metadata file in some way, and continue verification from there. This is will change with the [Vyper verification](https://github.com/ethereum/sourcify/pull/1784) and in our [APIv2](https://github.com/ethereum/sourcify/milestone/18?closed=1). In Vyper, users will give us a [standard JSON](https://docs.vyperlang.org/en/stable/compiling-a-contract.html#compiler-input-and-output-json-description) and we generate a "fake" metadata.json for backward compatability reasons. In our APIv2 we will no longer use the metadata file as the base of our verification, but the standard JSON as the base.
+For now the metadata.json is the main way to submit contracts to Sourcify. All other methods such as "Import from Etherscan" all workaround to generate the metadata file in some way, and continue verification from there. This is will change with the [Vyper verification](https://github.com/argotorg/sourcify/pull/1784) and in our [APIv2](https://github.com/argotorg/sourcify/milestone/18?closed=1). In Vyper, users will give us a [standard JSON](https://docs.vyperlang.org/en/stable/compiling-a-contract.html#compiler-input-and-output-json-description) and we generate a "fake" metadata.json for backward compatability reasons. In our APIv2 we will no longer use the metadata file as the base of our verification, but the standard JSON as the base.
 
 <details>
 <summary>Example metadata.json file</summary>
diff --git a/docs/2. Running Sourcify/EmbedReadmeMonitor.jsx b/docs/2. Running Sourcify/EmbedReadmeMonitor.jsx
@@ -1,6 +1,6 @@
 import EmbedReadme from "../EmbedReadme";
 import React from "react";
-const repo = "ethereum/sourcify";
+const repo = "argotorg/sourcify";
 const branch = "master";
 const readmePath = "/services/monitor/README.md";
 const rawBaseUrl = "https://raw.githubusercontent.com";
diff --git a/docs/2. Running Sourcify/EmbedReadmeServer.jsx b/docs/2. Running Sourcify/EmbedReadmeServer.jsx
@@ -1,6 +1,6 @@
 import EmbedReadme from "../EmbedReadme";
 import React from "react";
-const repo = "ethereum/sourcify";
+const repo = "argotorg/sourcify";
 const branch = "master";
 const readmePath = "/services/server/README.md";
 const rawBaseUrl = "https://raw.githubusercontent.com";
diff --git a/docs/20. databaseMigration.md b/docs/20. databaseMigration.md
@@ -15,8 +15,8 @@ It is meant for anyone running their own Sourcify instance.
 
 Currently Sourcify stores verified contracts into a repository:
 
-- in which there are contracts verified with old verification and storage strategies: [#902](https://github.com/ethereum/sourcify/issues/902), [#1071](https://github.com/ethereum/sourcify/issues/1071)
-- in which the sources are stored mirroring the original file system, causing naming path problems: [#515](https://github.com/ethereum/sourcify/issues/515)
+- in which there are contracts verified with old verification and storage strategies: [#902](https://github.com/argotorg/sourcify/issues/902), [#1071](https://github.com/argotorg/sourcify/issues/1071)
+- in which the sources are stored mirroring the original file system, causing naming path problems: [#515](https://github.com/argotorg/sourcify/issues/515)
 - filesystem based, causing a difficult maintenance and expansive advanced searches (e.g. by contract's name)
 
 ## New storage structure
diff --git a/docs/3. Verification/1.howToVerify.mdx b/docs/3. Verification/1.howToVerify.mdx
@@ -76,7 +76,7 @@ The verification UI will parse the files and give you a list of contracts to cho
 
 ### (Optional) Creation Transaction Hash 
 
-Sourcify needs to find the transaction the contract was deployed in to get the creation bytecode. We get this information from different sources like block explorers (see [here](https://github.com/ethereum/sourcify/blob/staging/services/server/src/sourcify-chains-default.json)). You can still provide a creation transaction hash manually if you want to, or if Sourcify fails to verify via creation bytecode.
+Sourcify needs to find the transaction the contract was deployed in to get the creation bytecode. We get this information from different sources like block explorers (see [here](https://github.com/argotorg/sourcify/blob/staging/services/server/src/sourcify-chains-default.json)). You can still provide a creation transaction hash manually if you want to, or if Sourcify fails to verify via creation bytecode.
 
 ### Hardhat/Foundry build-info files
 
diff --git a/docs/3. Verification/6. localNetwork.md b/docs/3. Verification/6. localNetwork.md
@@ -18,7 +18,7 @@ $ curl localhost:8545 -X POST --data '{"jsonrpc":"2.0","method":"net_version","p
 {"jsonrpc":"2.0","id":67,"result":"31337"}
 ```
 
-Similar to [adding EVM chains](/docs/chain-support) add the chain to [`sourcify-chains-default.json`](https://github.com/ethereum/sourcify/blob/staging/services/server/sourcify-chains-default.json), or to override all other chains you can simply create a new file `sourcify-chains.json` in the same directory. For example, to add the Hardhat Network:
+Similar to [adding EVM chains](/docs/chain-support) add the chain to [`sourcify-chains-default.json`](https://github.com/argotorg/sourcify/blob/staging/services/server/sourcify-chains-default.json), or to override all other chains you can simply create a new file `sourcify-chains.json` in the same directory. For example, to add the Hardhat Network:
 
 ```js
 ...
diff --git a/docs/4. repository/1. sourcify-database.mdx b/docs/4. repository/1. sourcify-database.mdx
@@ -7,7 +7,7 @@ On a high level, these modifications are:
 - Stores the [Solidity metadata](/docs/metadata) separately in the `sourcify_matches` table.
 - Introduces tables for other purposes.
 
-You can follow the [`services/database/migrations`](https://github.com/ethereum/sourcify/tree/staging/services/database/migrations) folder for the initial schema and the changes made to it. These are not necessarily the differences between Sourcify DB and the Verified Alliance Schema, but any changes made to the schema over time.
+You can follow the [`services/database/migrations`](https://github.com/argotorg/sourcify/tree/staging/services/database/migrations) folder for the initial schema and the changes made to it. These are not necessarily the differences between Sourcify DB and the Verified Alliance Schema, but any changes made to the schema over time.
 
 ## Schema
 
@@ -45,11 +45,11 @@ JSON fields of `compiled_contracts` table:
 
 ### Notes on the data
 
-For the issues on the data we are aware of and plan to fix, see this issue: https://github.com/ethereum/sourcify/issues/2276 
+For the issues on the data we are aware of and plan to fix, see this issue: https://github.com/argotorg/sourcify/issues/2276 
 
 Other known inconsistencies in the data below (not planned to fix) are documented below:
 
-- **Compiler versions**: Keep in mind the vyper version build strings are not consistent (details [here](hhttps://github.com/ethereum/sourcify/issues/2247#issuecomment-3155878775)):
+- **Compiler versions**: Keep in mind the vyper version build strings are not consistent (details [here](hhttps://github.com/argotorg/sourcify/issues/2247#issuecomment-3155878775)):
   - version =< 0.3.0: The commit hash has 7 characters `0.3.0+commit.8a23feb`
   - version 0.3.1: No commit hash: `0.3.1`
   - version >= 0.3.2: The commit hash has 8 characters `0.3.2+commit.3b6a4117`
diff --git a/docs/4. repository/index.mdx b/docs/4. repository/index.mdx
@@ -7,7 +7,7 @@ Sourcify stores the contracts in multiple storage backends and gives the option
 - `SourcifyDatabase`
 - `AllianceDatabase`
 
-For details see [Choosing the storage backend](https://github.com/ethereum/sourcify/tree/staging/services/server#choosing-the-storage-backend).
+For details see [Choosing the storage backend](https://github.com/argotorg/sourcify/tree/staging/services/server#choosing-the-storage-backend).
 
 ## Download
 
diff --git a/docs/95. requestChainSupport.md b/docs/95. requestChainSupport.md
diff --git a/docs/96. supportedChains.mdx b/docs/96. supportedChains.mdx
diff --git a/docs/EmbedReadmeIntro.jsx b/docs/EmbedReadmeIntro.jsx
diff --git a/docs/supportedChainsTable.tsx b/docs/supportedChainsTable.tsx
diff --git a/docusaurus.config.js b/docusaurus.config.js
