circlefin · taotao-circle · Oct 17, 2023 · Oct 11, 2023 · Oct 12, 2023 · Oct 12, 2023
diff --git a/LICENSE b/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2022 CENTRE CONSORTIUM, LLC
+Copyright (c) 2023 Circle Internet Financial Limited
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/README.md b/README.md
@@ -163,7 +163,7 @@ Occasionally, the local hardhat ethereum node and MetaMask become out of sync. I
 
 ## Contributors
 
-- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io))
+- [Kim Hamilton Duffy](https://github.com/kimdhamilton)
 - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com))
 - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz))
 - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz))

diff --git a/packages/contract/LICENSE b/packages/contract/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2022 CENTRE SECZ
+Copyright (c) 2023 Circle Internet Financial Limited
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/contract/README.md b/packages/contract/README.md
@@ -132,7 +132,7 @@ Since the full, fixed supply is issued to the contract creator, we used that sam
 
 ## Contributors
 
-- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io))
+- [Kim Hamilton Duffy](https://github.com/kimdhamilton) 
 - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com))
 - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz))
 - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz))
diff --git a/packages/contract/contracts/IVerificationRegistry.sol b/packages/contract/contracts/IVerificationRegistry.sol
@@ -1,7 +1,7 @@
 /**
  * SPDX-License-Identifier: MIT
  *
- * Copyright (c) 2018-2022 CENTRE SECZ
+ * Copyright (c) 2023 Circle Internet Financial Limited
  *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/contract/contracts/PermissionedToken.sol b/packages/contract/contracts/PermissionedToken.sol
@@ -1,7 +1,7 @@
 /**
  * SPDX-License-Identifier: MIT
  *
- * Copyright (c) 2018-2022 CENTRE SECZ
+ * Copyright (c) 2023 Circle Internet Financial Limited
  *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/contract/contracts/ThresholdToken.sol b/packages/contract/contracts/ThresholdToken.sol
@@ -1,7 +1,7 @@
 /**
  * SPDX-License-Identifier: MIT
  *
- * Copyright (c) 2018-2022 CENTRE SECZ
+ * Copyright (c) 2023 Circle Internet Financial Limited
  *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/contract/contracts/VerificationRegistry.sol b/packages/contract/contracts/VerificationRegistry.sol
@@ -1,7 +1,8 @@
 /**
  * SPDX-License-Identifier: MIT
  *
- * Copyright (c) 2018-2022 CENTRE SECZ
+ * Copyright (c) 2023 Circle Internet Financial Limited
+
  *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/contract/hardhat.config.ts b/packages/contract/hardhat.config.ts
@@ -256,7 +256,7 @@ task(
     }
 
     const verificationResult = {
-      schema: "centre.io/credentials/kyc",
+      schema: "",
       subject: taskArgs.address,
       expiration: Math.floor(Date.now() / 1000) + 60 // 1 minute
     }

diff --git a/packages/contract/scripts/deploy.ts b/packages/contract/scripts/deploy.ts
@@ -118,7 +118,7 @@ async function registerVerifications(registry: Contract, addresses: string[]) {
 
   for (const address of addresses) {
     const verificationResult = {
-      schema: "centre.io/credentials/kyc",
+      schema: "",
       subject: address,
       expiration: expiration
     }
@@ -151,9 +151,9 @@ async function createTrustedVerifier(
 ) {
   for (const address of verifiers) {
     const testVerifierInfo = {
-      name: hre.ethers.utils.formatBytes32String("Centre Consortium"),
-      did: "did:web:centre.io",
-      url: "https://centre.io/about",
+      name: hre.ethers.utils.formatBytes32String("Circle Internet Financial"),
+      did: "did:web:circle.com",
+      url: "https://www.circle.com/en/about-circle",
       signer: address
     }
 

diff --git a/packages/contract/test/VerificationRegistryTests.ts b/packages/contract/test/VerificationRegistryTests.ts
@@ -33,9 +33,9 @@ describe("VerificationRegistry", function () {
 
   // create a test verifier
   const testVerifierInfo = {
-    name: ethers.utils.formatBytes32String("Centre Consortium"),
-    did: "did:web:centre.io",
-    url: "https://centre.io/about",
+    name: ethers.utils.formatBytes32String("Circle Internet Financial"),
+    did: "did:web:circle.com",
+    url: "https://www.circle.com/en/about-circle",
     signer: signer.address
   }
 
@@ -71,7 +71,7 @@ describe("VerificationRegistry", function () {
   })
 
   it("Should update an existing verifier", async function () {
-    testVerifierInfo.url = "https://centre.io"
+    testVerifierInfo.url = "https://circle.com"
     const setVerifierTx = await verificationRegistry.updateVerifier(
       contractOwnerAddress,
       testVerifierInfo
@@ -137,7 +137,7 @@ describe("VerificationRegistry", function () {
       ]
     }
     verificationResult = {
-      schema: "centre.io/credentials/kyc",
+      schema: "",
       subject: subjectAddress,
       expiration: expiration
     }
@@ -239,7 +239,7 @@ describe("VerificationRegistry", function () {
   // register owner as verified
   it("Should register token owner as verified", async function () {
     verificationResult = {
-      schema: "centre.io/credentials/kyc",
+      schema: "",
       subject: tokenOwner,
       expiration: expiration
     }

diff --git a/packages/demo-issuer/LICENSE b/packages/demo-issuer/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2022 CENTRE SECZ
+Copyright (c) 2023 Circle Internet Financial Limited
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/demo-issuer/README.md b/packages/demo-issuer/README.md
@@ -60,7 +60,7 @@ Note that this is contingent on metamask actually supporting Verite.
 
 ## Contributors
 
-- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io))
+- [Kim Hamilton Duffy](https://github.com/kimdhamilton) 
 - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com))
 - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz))
 - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz))
diff --git a/packages/demo-revocation/LICENSE b/packages/demo-revocation/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2022 CENTRE SECZ
+Copyright (c) 2023 Circle Internet Financial Limited
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/demo-revocation/README.md b/packages/demo-revocation/README.md
@@ -45,7 +45,7 @@ You can read more about the Next.js folder structure in [their documentation](ht
 
 ## Contributors
 
-- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io))
+- [Kim Hamilton Duffy](https://github.com/kimdhamilton) 
 - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com))
 - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz))
 - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz))
diff --git a/packages/demo-verifier/LICENSE b/packages/demo-verifier/LICENSE
@@ -1,4 +1,4 @@
-Copyright (c) 2022 CENTRE SECZ
+Copyright (c) 2023 Circle Internet Financial Limited
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/packages/demo-verifier/README.md b/packages/demo-verifier/README.md
@@ -60,7 +60,7 @@ Issuance to metamask, or some browser-based extension wallet, is very similar. S
 
 ## Contributors
 
-- [Kim Hamilton Duffy](https://github.com/kimdhamilton) ([Centre Consortium](https://centre.io))
+- [Kim Hamilton Duffy](https://github.com/kimdhamilton) 
 - [Sean Neville](https://github.com/psnevio) ([Xdotzero](http://xdotzero.com))
 - [Brice Stacey](https://github.com/bricestacey) ([M2 Labs](https://m2.xyz))
 - [Matt Venables](https://github.com/venables) ([M2 Labs](https://m2.xyz))
diff --git a/packages/docs/blog/2022-03-30-introducing_verite.md b/packages/docs/blog/2022-03-30-introducing_verite.md
@@ -20,9 +20,9 @@ The answer is Verifiable Credentials (VCs). VCs are on a web standards track and
 
 ## What Is Verite?
 
-Verite is a collaborative and open source initiative spearheaded by the [Centre Consortium](https://www.centre.io/). Centre's focus is to "provide the governance and standards for the future digital financial ecosystem." Verite is one output of the collaborative effort of Centre.
+Verite is a collaborative and open source initiative spearheaded by the Circle, and its focus is to "provide the governance and standards for the future digital financial ecosystem." Verite is one output of the collaborative effort.
 
-While contributions to the VCs standards themselves is important, and Centre is an active participant alongside the W3C, tools that make it easy to implement and leverage VCs are just as important. As such, Centre began work last year on Verite, an open source library designed to make managing VCs easier.
+While contributions to the VCs standards themselves is important, and Circle is an active participant alongside the W3C, tools that make it easy to implement and leverage VCs are just as important. As such, Circle began work last year on Verite, an open source library designed to make managing VCs easier.
 
 Currently available in TypeScript and [published through NPM](https://www.npmjs.com/package/verite), the Verite library seeks to make it easier to implement VCs in a variety of forms. The library is early and an additional goal of the library is to collect community feedback.
 
@@ -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

diff --git a/packages/docs/blog/2022-04-13-crossfunctionality.md b/packages/docs/blog/2022-04-13-crossfunctionality.md
@@ -4,7 +4,7 @@ description: A business developer's guide to Semantics, and an engineer's guide
 slug: crossfunctionationality
 authors:
   - name: Juan Caballero
-    title: Standards Coordinator, Centre.io (Verite)
+    title: Standards Coordinator, Verite
     url: https://github.com/bumblefudge
     image_url: https://avatars.githubusercontent.com/u/37127325?v=4
 tags: [updates]
@@ -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

diff --git a/packages/docs/blog/2022-05-09-how_to_create_a_verification_registry_solidity.md b/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 Centre. 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.
 

diff --git a/packages/docs/blog/2022-06-15-verifiable_credentials_and_verite_nft_allowlist.md b/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.

diff --git a/packages/docs/blog/2022-07-27-verification_patterns_2.md b/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.
@@ -94,4 +94,4 @@ You could say that the crypto wallet delegates the encapsulation and signature o
 
 Circle’s implementation of the Verite protocol allows us to serve our customers and the dApps they interact with equally, putting the rigor of our KYC processes at the service of a process that is auditable and verifiable end-to-end without duplicating KYC process or PII from those processes across the chain of asset custody. We are proud to be driving the Verite process, and welcome more implementations, whether end-to-end issuer+verifier solutions like ours or more focused implementations that bring more wallets and more users into the ecosystem.
 
-As the Centre team updates its documentation and sample implementation to reflect the new patterns and flows, we will continue to work with them to share the insights we are gaining from our exploratory work with dApps and clients.
+As the Circle team updates its documentation and sample implementation to reflect the new patterns and flows, we will continue to work with them to share the insights we are gaining from our exploratory work with dApps and clients.
diff --git a/packages/docs/blog/2023-03-06-year_in_review.md b/packages/docs/blog/2023-03-06-year_in_review.md
@@ -4,7 +4,7 @@ description: A Year in Review
 slug: year-in-review-2023
 authors:
   - name: Juan Caballero
-    title: Standards Coordinator, Centre.io (Verite)
+    title: Standards Coordinator, Verite
     url: https://github.com/bumblefudge
     image_url: https://avatars.githubusercontent.com/u/37127325?v=4
 tags: [governance, research, roadmap]
@@ -38,7 +38,7 @@ The role of governance in the system shifted substantially over the past year. W
 
 In particular, we worried that on-chain communication would be the hardest to align on given the business model pressures of this new 4-actor model. While "schema design", as we had been calling it, sounded like a relatively simple technical question of data modeling, it turned out to be a far more complex beast across different chains of reliance and architectural variants.
 
-For this reason, less schema design happened in Centre-hosted working groups than we had expected. As end-to-end products continue to evolve, this kind of alignment could perhaps be premature, and many Verite partners have opted to defer this kind of harmonization until after there is significant adoption and traction. The schemas published so far are adequate to geographically-limited launches of the initial use-case, and as the sphere of supported geographies and use-cases expands, or as more players enter the space and demand grows for federation and interoperability, we look forward to truly viable self-governance. In the meantime, we will continue technical research and design work that falls into four categories:
+For this reason, less schema design happened in Circle-hosted working groups than we had expected. As end-to-end products continue to evolve, this kind of alignment could perhaps be premature, and many Verite partners have opted to defer this kind of harmonization until after there is significant adoption and traction. The schemas published so far are adequate to geographically-limited launches of the initial use-case, and as the sphere of supported geographies and use-cases expands, or as more players enter the space and demand grows for federation and interoperability, we look forward to truly viable self-governance. In the meantime, we will continue technical research and design work that falls into four categories:
 
 1. On-chain Design
 2. Architectural Design & Adoption