Strike plain language uses of 'Centre'.

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]

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/centrehq/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-07-27-verification_patterns_2.md

@@ -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.

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

packages/docs/verite/appendix/primer.md

@@ -89,7 +89,7 @@ Verite's demo wallet generates and manages DIDs and associated key pairs on beha
 
 In a typical decentralized identity case, a verifier would request a Verifiable Credential from an identity holder. That requires discovery or knowledge of the holder first _(simple analogy: someone asks you to prove you are vaccinated)_.
 
-But Centre’s use cases can also involve no knowledge of a holder endpoint at first, in which verifiers query the peer network to find one or more DIDs that can satisfy the claim in the query using a particular Verifiable Credential _(simple analogy: someone posts a notice in a public place asking to be privately and anonymously messaged by anyone who chooses to prove they are vaccinated)_.
+But Circle's use cases can also involve no knowledge of a holder endpoint at first, in which verifiers query the peer network to find one or more DIDs that can satisfy the claim in the query using a particular Verifiable Credential _(simple analogy: someone posts a notice in a public place asking to be privately and anonymously messaged by anyone who chooses to prove they are vaccinated)_.
 
 **VC Structure**
 

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 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/centrehq/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/issuers/getting-started.md

@@ -112,10 +112,6 @@ Take a minute to ask yourself some difficult strategic questions:
   your support to wallets with built-in per-transaction or per-session
   biometrics, etc.
 
-Over time, we will be updating and detailing this guidance, but in the meantime,
-feel free to reach out to [the Verite team at
-Centre.io](mailto:[email protected]) for guidance on where to start and which
-wallets are already supporting these interfaces.
 
 ## Architectural options
 
@@ -147,7 +143,4 @@ Once you have clear your use-cases and your high-level architecture, you arrive
 at the build-or-buy decision. If you want to issue the credentials you will be
 responsible for yourself, there are tutorials and documents to guide you through
 the process in the ["For Developers" section of this
-site](https://verite.id/verite/developers/getting-started). If you are curious
-about credential Issuance-as-a-Service, reach out to [the Verite team at
-Centre.io](mailto:[email protected]) and we can refer you to colleagues in the
-space operating on this kind of model.
+site](https://verite.id/verite/developers/getting-started).

packages/docs/verite/issuers/issuer-registry-pvg.md

@@ -8,7 +8,7 @@ The issuer registry pre-viable governance (PVG) is a simple demonstration issuer
 
 ## Usage/Intent of the PVG Verite Issuer Registry
 
-The PVG Verite Issuer Registry focuses exclusively on Issuer ID and authorization and leaves out of scope governance considerations. As such, this should be viewed as an experimental implementation for the initial Verite issuers as the governance structure is being developed, with only manual and Centre-governed additions and removals until such a time as Verite issuance can be communally self-governing.
+The PVG Verite Issuer Registry focuses exclusively on Issuer ID and authorization and leaves out of scope governance considerations. As such, this should be viewed as an experimental implementation for the initial Verite issuers as the governance structure is being developed, with only manual and Circle-governed additions and removals until such a time as Verite issuance can be communally self-governing.
 
 The PVG Verite Issuer Registry identifies entities authorized to issue Verite credentials (segmented by different credential definitions); for each, it provides the exact issuer-service identifier (usually a DID) included in their Verite credentials, along with associated metadata. 
 
@@ -39,7 +39,7 @@ All is to be interpreted as experimental for PVG and subject to revision.
 
 The following roles are referred to below
 - Verite owners/administrators: 
-    - Initially Verite github repo (centrehq) administrators.
+    - Initially Verite github repo administrators.
     - Sole technical/logistic ability to approval and merge PRs 
     - Later to be replaced with real governance/membership scheme
 - Verite participants:
@@ -56,6 +56,6 @@ The following roles are referred to below
     - Organization must sign Verite CLA
     - No substantive objections from WG members, as determined by WG chair
 - Process for updates to issuer registry:
-    - Any individual by any organization covered by Verite CLA may open PR against Centre Verite github org 
+    - Any individual by any organization covered by Verite CLA may open PR against the Verite github org 
     - Verite repo owners/administrators must review, approve, and merge
     - Github signed commits are required (they are enabled repo-wide on Verite github repo)

packages/docs/verite/overview/design-overview.md

@@ -15,7 +15,7 @@ Verite's decentralized identity standards aim to satisfy the following design pr
 
 - **Cryptographically verifiable:** Based on cryptographic proofs rather than out-of-band trust.
 
-- **Resolvable and interoperable:** Open to any solution that recognizes the common protocols and data model and requires no one specific software vendor implementation, including any that Centre or its members may create.
+- **Resolvable and interoperable:** Open to any solution that recognizes the common protocols and data model and requires no one specific software vendor implementation, including any that Circle or its members may create.
 
 - **Transparent:** Identity holders know when and how their identity data is being requested and used.
 
@@ -27,7 +27,7 @@ Interoperability across the ecosystem is an over-arching Verite goal. There has
 
 Verite's specific tactical goals are to: (a) define data models (schemas) that should be shared and exist as common building blocks for all parties as a public good; and (b) define the protocols for requesting and delivering identity claims in a manner that supports crypto finance use cases.
 
-The intent is to enable any member of the broader crypto ecosystem to develop products and solutions that are inherently compliant and interoperable with each other, and to do so in a manner that is open, transparent, and usable by anyone, whether connected to the Centre Consortium and the USDC ecosystem or not.
+The intent is to enable any member of the broader crypto ecosystem to develop products and solutions that are inherently compliant and interoperable with each other, and to do so in a manner that is open, transparent, and usable by anyone, whether connected to Circle and the USDC ecosystem or not.
 
 A process goal is to maintain transparency and openness in the iteration of the protocols and data models. Anyone is free to use the source code, modify it, and submit improvements to it.
 

packages/docs/verite/overview/governance-overview.md

@@ -17,7 +17,7 @@ In a network with multiple issuers, every VC issued should be on equal footing.
 
 ## Current State: Boot-strapping an Ecosystem
 
-Verite is currently orchestrated by Centre in close collaboration with its initial implementers, and grounded in feedback from early evaluators who commit seriously to considering our work to date.  This is “strategically centralized,” in the sense that Centre is currently the hub at the center of major technical and business planning with implementers, but the multi-lateral collaboration has already started in Working Groups, bound by multi-lateral IP/NDA agreements.  One such working group is actually focused on roadmapping and elaborating everything that follows; to get involved, reach out to Centre.
+Verite is currently orchestrated by Circle in close collaboration with its initial implementers, and grounded in feedback from early evaluators who commit seriously to considering our work to date.  This is “strategically centralized,” in the sense that Circle is currently the hub at the center of major technical and business planning with implementers, but the multi-lateral collaboration has already started in Working Groups, bound by multi-lateral IP/NDA agreements.  One such working group is actually focused on roadmapping and elaborating everything that follows; to get involved, reach out to Circle.
 
 ## Target-State: Three Interlocking Governance Mechanisms
 
@@ -56,11 +56,11 @@ The governance framework will define (not exhaustive):
 
 The “**Network Utilities**” that power Verite provide common services to all participants and end-users in the Verite ecosystem. 
 
-The first and most structural network utility is the **Trusted Identity Registry**. The Trusted Identity Registry defines which Issuers and Verifiers can be trusted to adhere to Centre Verite Standards.  It functions as an “key directory” providing authoritative key material to prevent phishing or impersonation within the system. As Verite scales up, it will also include up-to-date information on conformance testing, to facilitate real-time decision making about the trustworthiness and roadworthiness of each actor’s implementation and credentials.  Centre reserves the right to remove actors from the Registry if they have not signed the Rulebook or have been judged by the community not to be honoring it.
+The first and most structural network utility is the **Trusted Identity Registry**. The Trusted Identity Registry defines which Issuers and Verifiers can be trusted to adhere to Circle Verite Standards.  It functions as an “key directory” providing authoritative key material to prevent phishing or impersonation within the system. As Verite scales up, it will also include up-to-date information on conformance testing, to facilitate real-time decision making about the trustworthiness and roadworthiness of each actor’s implementation and credentials.  Circle reserves the right to remove actors from the Registry if they have not signed the Rulebook or have been judged by the community not to be honoring it.
 
 #### Detailed Remit: Trusted Identity Registry  
 
-Centre will build, maintain, and publish the Trusted Identity Registry that includes Issuers and Verifiers which have applied for and been approved by the Verite Governance Board to join the registry. 
+Circle will build, maintain, and publish the Trusted Identity Registry that includes Issuers and Verifiers which have applied for and been approved by the Verite Governance Board to join the registry. 
 Entities in the registry adhere to technical, operational, legal, regulatory, and compliance standards defined by Verite Governance Board. 
 Verifiers and Issuers in the registry must sign a Verite Rulebook which defines the rights, obligations, standards, reps & warranties, etc that they must adhere to. 
 The rulebook dictates the conditions under which a VC can be issued, verified, and or/revoked
@@ -91,6 +91,3 @@ The Verite Rulebook will cover a number of different topics, including but not l
 * Financial requirements of the issuers/verifiers 
 * SLAs for the network utilities (e.g. uptime, resiliency, latency, etc)
 
-## Roadmap
-
-We are in the early stages of defining the "minimum viable governance" with key stakeholders as we establish the ecosystem. If you’re interested in participating, please contact us at [email protected] 

packages/docs/verite/patterns/travel-rule.md

@@ -6,7 +6,7 @@ sidebar_position: 7
 
 The Verite open source repo includes some code that provides a cursory demonstration of how exchanging verifiable credentials could be a core component of scalable and open ecosystems for financial institutions to comply with Travel Rule reporting obligations with minimal privacy, data leakage, and security risks.
 
-In addition to this high-level "proof of concept," long-tail research in ongoing into FATF use cases forming a cornerstone of Verite in the latter part of 2023. To get involved with the research team, contact Verite's [Standards team at Centre.io](mailto:[email protected]).  
+In addition to this high-level "proof of concept," long-tail research in ongoing into FATF use cases forming a cornerstone of Verite in the latter part of 2023. 
 
 Please note: TRUST, TRISA, and other protocols that currently do not use Verifiable Credentials as an exchange format for FATF counterparty reporting are in no way incompatible with this group's approach; our goal is to focus on the privacy risks and protocols for mutual discovery and interactions, which can bootstrap any protocol between financial institutions once validated.