Fix typos

README.md

@@ -2,7 +2,7 @@
 
 Decentralized Identity for Crypto Finance.
 
-This repository is a monorepo containing the Core Verite Javascript SDK, documentation, as well as several demos to illustrate issuance, verification, revocation, and real-world use-cases of the Verite standard.
+This repository is a monorepo containing the Core Verite Javascript SDK, documentation, as well as several demos to illustrate issuance, verification, revocation, and real-world use cases of the Verite standard.
 
 ## Getting Started
 
@@ -68,7 +68,7 @@ Running an Ethereum node is easily accomplished by using our built-in scripts fo
 npm run hardhat:node
 ```
 
-Now you have a local Ethereum node running. This process is long-lived and should remain open in it's own terminal tab.
+Now you have a local Ethereum node running. This process is long-lived and should remain open in its own terminal tab.
 
 2. Next, you will need to deploy the smart contracts to the local Ethereum network.
 

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

@@ -14,7 +14,7 @@ Please note: TRUST, TRISA, and other protocols that currently do not use Verifia
 
 The "Travel Rule" refers to the [U.S. Bank Secrecy Act rule](https://www.sec.gov/about/offices/ocie/aml2007/fincen-advissu7.pdf) as well as guidance defined by the international [Financial Action Task Force (FATF) Recommendation 16](https://www.fatf-gafi.org/publications/fatfrecommendations/documents/guidance-rba-virtual-assets-2021.html). The Travel Rule requires Financial Institutions (FIs) and what FATF refers to as Virtual Asset Service Providers (VASPs) to exchange and analyze specific PII data about the originator and beneficiary of a given transaction when such a transaction exceeds a threshold of notional value (the threshold is 3000 USD value for the US BSA version and 1000 USD/EUR value for FATF version). The purpose of these regulations is to police financial crime such as money laundering, block terrorist financing, stop payments to sanctioned entities and countries by requiring intermediaries to report threshold-exceeding transaction and combine those reports with other monitoring to detect and investigate suspicious activities.  Since most prosecution and tort discovery of these crimes leans heavily on forensics, this reporting is often archival in nature and format.
 
-Mapping Travel Rule requirements to blockchain transactions poses several challenges. One such problem is "discoverablility" -- knowing when a beneficiary/recipient address is managed by a financial institution and therefore when Travel Rule obligations exist, and furthermore how to contact the recipient institution to execute secure counterparty data exchange. At broadcast time, the originator of a blockchain transaction has no means of knowing whether a recipient address is custodied by a financial institution or VASP, much less which one, and furthermore no means of directly contacting the owner or custodian of that address.
+Mapping Travel Rule requirements to blockchain transactions poses several challenges. One such problem is "discoverability" -- knowing when a beneficiary/recipient address is managed by a financial institution and therefore when Travel Rule obligations exist, and furthermore how to contact the recipient institution to execute secure counterparty data exchange. At broadcast time, the originator of a blockchain transaction has no means of knowing whether a recipient address is custodied by a financial institution or VASP, much less which one, and furthermore no means of directly contacting the owner or custodian of that address.
 
 The crypto ecosystem has proposed many potential solutions to this problem over time: 
 - maintaining registries of known blockchain addresses mapped to VASP network endpoints, 
@@ -61,7 +61,7 @@ Since the transaction amount is not included, observers are unable to determine
 4. Optionally, Alice's FI could elect to support a "**Suspicious mode**" (i.e. supporting an optional authentication step) by additionally including in M1:
    - A secure callback URL endpoint for requesting proof-of-control credentials by M1 message identifier after establishing trust (see below)
 5. Alice's FI publishes M1 to the decentralized bulletin board.
-6. Bob's financial institution observes M1 being emitted in the bulletin board, verifies that the recipient address is in its custody, and responds acordingly.
+6. Bob's financial institution observes M1 being emitted in the bulletin board, verifies that the recipient address is in its custody, and responds accordingly.
 
 ### Part 2: Trust Establishment: i.e. Exchange of Public Credentials
 
@@ -83,7 +83,7 @@ The trust establishment step (which some might think of as an "anti-spam"/"anti-
 
 If Alice's FI determines the transaction does not meet the threshold required for the Travel Rule after establishing both Alice's and Bob's requirements by jurisdiction, then Part 3 is not necessary and does not apply, as Alice's FI can simply proceed to broadcasting the blockchain transaction. 
 
-If the Travel Rule does apply, however, both financial institutions are able to exchange counterparty verifiable credentials over callback URLs that allow for private  secure communication. This can happen over any secure channel, and today is mostly done in consortium/network-like platforms that bundle the authentication of step 2 and the secure channel for step 3 (as well as data dictionaries or translation enginges for exchanging the actual information required by applicable reporting requirements, itself a massively complex value-add and rules engine).  This research could be called long-tail, as the rapid pace of regulatory change here means the existing protocols will probably be distracted updating their rules engines for some time and not have bandwidth to consider harmonizing on UX and consent flows!
+If the Travel Rule does apply, however, both financial institutions are able to exchange counterparty verifiable credentials over callback URLs that allow for private  secure communication. This can happen over any secure channel, and today is mostly done in consortium/network-like platforms that bundle the authentication of step 2 and the secure channel for step 3 (as well as data dictionaries or translation engines for exchanging the actual information required by applicable reporting requirements, itself a massively complex value-add and rules engine).  This research could be called long-tail, as the rapid pace of regulatory change here means the existing protocols will probably be distracted updating their rules engines for some time and not have bandwidth to consider harmonizing on UX and consent flows!
 
 As a prototype of user-centric UX and an architecture that layers consent receipts on top of reporting artefacts, the Verite prototype models how identity-enabled and verifiable-credential-enabled wallets could surface meaningful and direct consent into such a flow. While traditional financial institutions typically require their users to consent to terms and conditions that grant the rights to transfer this kind of private information, this prototype of more proactive and per-interaction consent could pave the way to better support for non-custodial wallet compliance, or conformance to more aggressive regulation about meaningful consent.  To address this latter hypothetical requirement, the flow presents notifications as alerts to customers so that they have visibility into when their data is requested, and to provide them the choice to cancel sending or receiving transactions that require such counterparty credentials exchange.
 

packages/docs/verite/patterns/verification-flow.md

@@ -82,7 +82,7 @@ In this example, a user wants to verify address-bound credentials issued to a bl
 2. Relying Party (e.g. Dapp) calls Verifier with wallet address to be verified.
 3. Verifier returns [Presentation Request][] (no additional properties required).
 
-5. Verifier prompts user to connect the wallet controlling the blockcain address that the Verification Record will be bound to.
+5. Verifier prompts user to connect the wallet controlling the blockchain address that the Verification Record will be bound to.
 6. Wallet signs an offchain transaction to authenticate wallet and authorize a web3 session. For interoperability and auditing purposes, we recommend a [EIP-4361][]-conformant "Sign-In With Ethereum" message or a [CAIP-122][]-conformant equivalent.
 7. Verifier sends its [Presentation Request][] to wallet, or equivalent bespoke RPC calls describing the acceptable credentials.
 8. The Wallet checks its storage for one or more matching credentials.  If more than one is present, a user selection step should be triggered; if none, a redirect or informative message displayed.  If exactly one, consent step may be optional, depending on use-case.
@@ -98,4 +98,4 @@ In this example, a user wants to verify address-bound credentials issued to a bl
 [Presentation Submission]: https://identity.foundation/presentation-exchange/#presentation-submission
 [EIP-4361]: https://eips.ethereum.org/EIPS/eip-4361#example-message
 [CACAO]: https://github.com/ChainAgnostic/CAIPs/blob/c8d8ee203625ea622bd15c42b2493116712dfaf3/CAIPs/caip-74.md
-[CAIP-122]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-122.md
+[CAIP-122]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-122.md