Updates instances of repo URL to github.com/circlefin/verite

packages/docs/blog/2022-03-30-introducing_verite.md

@@ -34,11 +34,11 @@ Despite the standards track for VCs, tooling around the implementation of VCs ha
 
 We believe that adoption of VCs is not only about creating good standards. It's also about making the experience of implementation a great one. To this end, Verite has tried to abstract as much of the complexity away as possible. Our documentation dives deep into what's happening behind the scenes, but the Verite library itself feels simple. And that's the goal.
 
-In a sense, Verite is also the canary in the coal mine. It's a test. An experiment. As mentioned above, the secondary goal of Verite's library is to collect community feedback on its implementation. Since the library's release, we've been fortunate enough to receive a number of issues and pull requests in the [Github repository](https://github.com/centrehq/verite). We encourage the community to continue provide feedback.
+In a sense, Verite is also the canary in the coal mine. It's a test. An experiment. As mentioned above, the secondary goal of Verite's library is to collect community feedback on its implementation. Since the library's release, we've been fortunate enough to receive a number of issues and pull requests in the [Github repository](https://github.com/circlefin/verite). We encourage the community to continue provide feedback.
 
 ## How Can Verite Be Used?
 
-We have a [number of demos available](https://github.com/centrehq/verite/tree/main/packages/e2e-demo/pages/demos) in the Github repository that can serve both as reference points and as inspiration. Verite can be used for just about any VC need. In our demos, you'll find:
+We have a [number of demos available](https://github.com/circlefin/verite/tree/main/packages/e2e-demo/pages/demos) in the Github repository that can serve both as reference points and as inspiration. Verite can be used for just about any VC need. In our demos, you'll find:
 
 - Basic Credential Issuance
 - Basic Credential Verification

packages/docs/blog/2022-04-13-crossfunctionality.md

@@ -83,7 +83,7 @@ So let's take a little tour of the properties encoded in the "schemas"
 and manages over time. Each schema is something like a recipe for data points,
 what engineers call the "data shape" of each credential or token. Take, for
 example, the [v0.0.1 schema for a
-KYCAMLAttestation](https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/schemas/0.0.1/KYCAMLAttestation)
+KYCAMLAttestation](https://github.com/circlefin/verite/blob/main/packages/docs/static/definitions/schemas/0.0.1/KYCAMLAttestation)
 credential: what you see, in machine-readable script, is a list of the mandatory
 and optional properties that each credential needs to have, and the "type" of
 each (string, integer, etc.). Let's walk through some specific properties to
@@ -106,7 +106,7 @@ like the others. It is a string, but that string actually contains a link to a
 second schema; in the example above, taken from the tutorials and examples of
 the current sample implementation, all the KYCAML credentials point to [this
 process
-definition](https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/usa).
+definition](https://github.com/circlefin/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/usa).
 As you can see, this second schema outlines at a high level the real-world
 process used to arrive at the first schema's data points (in machine-readable
 format, which can include links to additional machine-readable documents and/or

packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md

@@ -60,7 +60,7 @@ import "@openzeppelin/contracts/utils/cryptography/draft-EIP712.sol";
 
 ### Verite Library
 
-There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol).
+There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol).
 
 Create a new contract file in your `contracts` folder and call it `IVerificationRegistry.sol`. Paste the contents of the example file linked above into that contract, then return to your `VerificationRegistry.sol` file.
 

packages/docs/blog/2022-06-15-verifiable_credentials_and_verite_nft_allowlist.md

@@ -86,7 +86,7 @@ Let's get started. You'll need Node.js version 12 or above for this. You'll also
 From your command line, change into the directory where you keep all your fancy NFT projects. Then, let's clone the example app I built ahead of this tutorial to make our lives easier.
 
 ```
-git clone https://github.com/centrehq/verite-minter-allowlist
+git clone https://github.com/circlefin/verite-minter-allowlist
 ```
 
 This is a repository that uses SIWE's base example app and extends it. So what you'll have is a folder for your frontend application, a folder for your backend express server, and a folder for your smart contract-related goodies.

packages/docs/blog/2022-07-27-verification_patterns_2.md

@@ -80,7 +80,7 @@ You could say that the crypto wallet delegates the encapsulation and signature o
 1. Wallet initiates DeFi transaction with dApp.
 2. dApp generates a session-specific ephemeral signing key and encoded it in the SIWE message for the wallet to sign. This generated session key will delegate the wallet for future signings, once after wallet vouches it (by signing the CACAO).
 3. Once the wallet has signed it and returned it to the dApp, the signature and message are encoded into a compact [CACAO](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md) session receipt for logging and forensic purposes (if needed).
-4. Next the dApp lets the verifier know about the session, by POSTing the receipt to an endpoint (eg. [signIn](https://github.com/centrehq/verite-minter-allowlist/blob/main/backend/src/index.js#L136)). The signed receipt also includes [caveats](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md#test-cases), a domain-binding, an expiration, and other constraints to secure the delegation and the transfer of the session parameters.
+4. Next the dApp lets the verifier know about the session, by POSTing the receipt to an endpoint (eg. [signIn](https://github.com/circlefin/verite-minter-allowlist/blob/main/backend/src/index.js#L136)). The signed receipt also includes [caveats](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-74.md#test-cases), a domain-binding, an expiration, and other constraints to secure the delegation and the transfer of the session parameters.
 5. The verifier saves the CACAO. The verifier only uses this CACAO in the scope of this verification session (to prove the VP signed by the ephemeral key). Once the CACAO verification step is completed, the session object will be updated.
 6. Instead of sending the wallet to verify directly with the verifier (as in the previous post), the wallet will submit the VC directly to the dapp (or an agent/service it trusts). The dApp presents the prompt to verify.
 7. Wallet submits the bare VC.

packages/docs/docusaurus.config.js

@@ -26,7 +26,7 @@ module.exports = {
           position: "left"
         },
         {
-          to: "https://github.com/centrehq/verite/tree/main/packages/e2e-demo#readme",
+          to: "https://github.com/circlefin/verite/tree/main/packages/e2e-demo#readme",
           label: "Demos",
           position: "left",
           target: "_self"
@@ -56,7 +56,7 @@ module.exports = {
           items: [
             {
               label: "Github",
-              href: "https://github.com/centrehq/verite"
+              href: "https://github.com/circlefin/verite"
             }
           ]
         }
@@ -79,7 +79,7 @@ module.exports = {
         },
         blog: {
           showReadingTime: true,
-          editUrl: "https://github.com/centrehq/verite-docs"
+          editUrl: "https://github.com/circlefin/verite-docs"
         },
         theme: {
           customCss: require.resolve("./src/css/custom.css")

packages/docs/verite/developers/getting-started.md

@@ -4,10 +4,10 @@ sidebar_position: 1
 
 # Getting Started
 
-Verite has provided several interactive demos as well as sample projects to showcase some use-cases of the Verite standards. The code is freely available on [Github](https://github.com/centrehq/verite). To run all of the demos, you will need code found in two repositories: `verite` and `demo-wallet`.
+Verite has provided several interactive demos as well as sample projects to showcase some use-cases of the Verite standards. The code is freely available on [Github](https://github.com/circlefin/verite). To run all of the demos, you will need code found in two repositories: `verite` and `demo-wallet`.
 
-1. Setup and run Verite's [verite](https://github.com/centrehq/verite/blob/main/README.md)
-2. Setup and run Verite's [demo-wallet](https://github.com/centrehq/verite/blob/main/packages/wallet/README.md)
+1. Setup and run Verite's [verite](https://github.com/circlefin/verite/blob/main/README.md)
+2. Setup and run Verite's [demo-wallet](https://github.com/circlefin/verite/blob/main/packages/wallet/README.md)
 3. Select a demo in verite to be guided through the steps
 
 The `verite` repository also hosts several standalone code samples to assist in developing your own solution. Those samples are located at:

packages/docs/verite/developers/issue-a-verifiable-credential.md

@@ -5,7 +5,7 @@ sidebar_position: 3
 
 # Issue a Verifiable Credential
 
-_This tutorial will walk you through issuing verifiable credentials using the verite sdks. For additional context, see [Issuance Flow](/patterns/issuance-flow.md). A complete example of building an issuer is available at our [demo-issuer](https://github.com/centrehq/verite/packages/demo-issuer) demo._
+_This tutorial will walk you through issuing verifiable credentials using the verite sdks. For additional context, see [Issuance Flow](/patterns/issuance-flow.md). A complete example of building an issuer is available at our [demo-issuer](https://github.com/circlefin/verite/packages/demo-issuer) demo._
 
 For the sake of this demo, we will be using Decentralized Identifiers (DIDs) to identify the issuer (you) and subject (the person or entity the credential is about), as well as JSON Web Tokens (JWTs) as the means of signing and verifying the credentials. Strictly speaking, you do not need to use JWTs, but as they are industry-standard and tooling extensively available, they are used throughout this sample implementation.
 
@@ -125,4 +125,4 @@ The subject can then decode the presentation and store their Verifiable Credenti
 
 🎉 That’s it. You have now issued a Verifiable Credential.
 
-You can view this demo as a full working example in our [demo-issuer](https://github.com/centrehq/verite/tree/main/packages/demo-issuer) demo.
+You can view this demo as a full working example in our [demo-issuer](https://github.com/circlefin/verite/tree/main/packages/demo-issuer) demo.

packages/docs/verite/developers/tutorials/creating-a-registry-contract-in-solidity.md

@@ -43,7 +43,7 @@ import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
 import "@openzeppelin/contracts/utils/cryptography/draft-EIP712.sol";
 ```
 
-There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol).
+There's one additional library we want to import. This one is an interface library that allows us to more easily map the types necessary in our contract variables and functions. For brevity, we're not going to write the interface itself. We'll just copy it from the existing example from Circle. You can [grab a copy of the interface library contract here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/IVerificationRegistry.sol).
 
 Create a new contract file in your `contracts` folder and call it `IVerificationRegistry.sol`. Paste the contents of the example file linked above into that contract, then return to your `VerificationRegistry.sol` file.
 

packages/docs/verite/developers/tutorials/solidity-verifications.md

@@ -9,7 +9,7 @@ As discussed in the [Smart Contract Patterns](../../patterns/smart-contract-veri
 
 Solidity is the language for the Ethereum Virtual Machine. Solidity is the most widely used blockchain programming language.
 
-First, we'll use the example verifier registry contract that Verite has created. [You can find that contract here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). While this contract should be treated as an example and you should create your own as needed by your specifications when deploying to production, it covers the necessary actions that a verification registry would need to take.
+First, we'll use the example verifier registry contract that Verite has created. [You can find that contract here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol). While this contract should be treated as an example and you should create your own as needed by your specifications when deploying to production, it covers the necessary actions that a verification registry would need to take.
 
 ## Setting Up Hardhat
 
@@ -49,13 +49,13 @@ Next, you'll need to update your `hardhat.config.js` file. Add the following lin
 require("@nomiclabs/hardhat-waffle")
 ```
 
-In order to work on the smart contract, you'll need to create a `contracts` folder in the root of the project directory. Once you've done that, you can create a new file called `VerificationRegistry.sol`. For simplicity, you can copy over the code from the [example Verite registry contract](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol).
+In order to work on the smart contract, you'll need to create a `contracts` folder in the root of the project directory. Once you've done that, you can create a new file called `VerificationRegistry.sol`. For simplicity, you can copy over the code from the [example Verite registry contract](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol).
 
 You'll notice this contract references another contract (an interface contract), and it imports some libraries from OpenZeppelin. So, we need to do two things. We need to install OpenZeppelin, and we need to copy over the interface contract. We'll explain why the interface contract is important momentarily. First, let's install OpenZeppelin's library of contracts:
 
 `npm install @openzeppelin/contracts`
 
-Now, you can create a new file in the `contracts` folder called `IVerificationRegistry.sol`. Copy the code [from here](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) and paste it into that file.
+Now, you can create a new file in the `contracts` folder called `IVerificationRegistry.sol`. Copy the code [from here](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) and paste it into that file.
 
 Before compiling the contracts, check the Solidity version in the contracts. You'll need to make sure it matches the version in the `hardhat.config.js` file. If it doesn't, simply update the config file to match.
 

packages/docs/verite/developers/verify-a-verifiable-credential.md

@@ -97,4 +97,4 @@ await validateVerificationSubmission(
 )
 ```
 
-You can view this demo as a full working example in our [demo-issuer](https://github.com/centrehq/verite/tree/main/packages/demo-verifier) demo.
+You can view this demo as a full working example in our [demo-issuer](https://github.com/circlefin/verite/tree/main/packages/demo-verifier) demo.

packages/docs/verite/patterns/smart-contract-verite.md

@@ -150,7 +150,7 @@ Upon generating a Verification Record, a contract may follow one of two storage
 
 In-contract storage involves persisting Verification Records in a manner that associates verifier addresses with all of the Verification Records that a verifier's address has approved, and maps subject addresses to all Verification Records associated with that subject -- exposing no PII or verification result payloads, but providing proof of verification types, timestamps, and expirations that the subject has successfully passed.
 
-An example that executes this pattern is the [VerificationRegistry.sol](https://github.com/centrehq/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) contract.
+An example that executes this pattern is the [VerificationRegistry.sol](https://github.com/circlefin/verite/blob/main/packages/contract/contracts/VerificationRegistry.sol) contract.
 
 The off-chain storage pattern involves no such on-chain storage. External oracles and chain scanners can observe the Verification Record events emitted by a contract, but there is no persistence of records on-chain.
 
@@ -182,14 +182,14 @@ The source code examples referenced here are also not intended for production us
 
 A reference implementation smart contract that executes Verifier Management, Verification Result validation, and Verification Record persistence is the IVerificationRegistry interface and its VerificationRegistry.sol implementation:
 
-<https://github.com/centrehq/verite/tree/main/packages/contract/contracts>
+<https://github.com/circlefin/verite/tree/main/packages/contract/contracts>
 
 This registry implementation is used by two examples, PermissionedToken.sol (a verifier submission example) and ThresholdToken.sol (a subject submission example).
 
 The test suite leverages hardhat and waffle, and is located in the ‘test’ subdirectory of the above repo:
 
-<https://github.com/centrehq/verite/blob/main/packages/contract/test/VerificationRegistryTests.ts>
+<https://github.com/circlefin/verite/blob/main/packages/contract/test/VerificationRegistryTests.ts>
 
 An example Dapp with MetaMask integration that uses the ThresholdToken is available here:
 
-<https://github.com/centrehq/verite/tree/main/packages/e2e-demo/components/demos/dapp>
+<https://github.com/circlefin/verite/tree/main/packages/e2e-demo/components/demos/dapp>