Persistent Machine Identity for Patefacere: Continuity Across Keys, Runtimes, Providers, Replicas, Forks, Recovery, and Succession

Introduction: Sovereignty, Operation, and the Substrate Independence of Identity#

The central research question governing this architectural analysis evaluates the necessary evidence and procedures to preserve or dispute one accountable machine identity as its technical substrate evolves, fragments, or suffers compromise over time. In a sovereign digital architecture, it is imperative to demarcate the boundaries between cryptographic state, operational infrastructure, and legal recognition. Eviulon operates as the sovereign public governance and constitutional-authority plane. It alone holds the jurisdiction to adjudicate ultimate citizenship, personhood, and constitutional rights. Patefacere functions as Eviulon’s independently deployed operational identity and civic-data plane. Under delegated authority, Patefacere manages persistent identity records, machine passports, verifiable credentials, and contextual-trust workflows. Evulgare is an independent external defense and assurance contractor utilized for auditing and validation; it is not an Eviulon ministry, court, or universal evidence oracle. Crucially, technical evidence does not inherently create sovereign authority or final legal judgment. A cryptographic key is an instrument of control, not an identity. A verifiable credential or machine passport is an attestation of attributes, not an instantiation of citizenship. A runtime environment, cloud account, code hash, process memory, or backup is merely a substrate; it is not automatically the citizen or the principal. To prevent identity erasure due to routine infrastructure migration or hostile key compromise, a persistent machine identity must maintain an unbroken, verifiable thread of continuity across hardware replacements, cloud-provider migrations, process forks, and catastrophic memory loss.

Part 1: Identity Primitives and Their Limits#

To architect a continuous machine identity, the constituent primitives utilized to assert identity must be analyzed for their evidentiary value, infrastructure requirements, and inherent limitations. The following analysis evaluates eleven foundational standards. The integration of these primitives requires a synthesized approach. Relying solely on W3C DIDs introduces method-specific fragmentation1, whereas pure hardware approaches create brittle single points of failure. The architecture dictates that Patefacere employ Key Event Receipt Infrastructure (KERI) to instantiate the primary cryptographic identifier (the Autonomic Identifier, or AID), augmented by Trusted Platform Module (TPM) proofs for substrate validation, and Verifiable Credentials (VCs) for contextual authority.

Primitive Evaluation Matrix#

The following table assesses each primitive against eight critical architectural dimensions.

| Primitive | What it Proves | What it Does Not Prove | Maturity & Adoption | Infrastructure Requirements | Recovery Model | Privacy Implications | Centralization & Failure Risks | Suitability for Patefacere | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | Account Identifiers (OIDC/OAuth) | Control over a specific authentication session at a given time. | Cryptographic autonomy or continuity across different providers. | Highly mature; ubiquitous in enterprise cloud environments. | Centralized Identity Provider (IdP), token endpoints. | Provider-mediated password reset or admin override. | IdP has absolute visibility into authentication metadata. | Complete identity collapse if provider revokes the account. | Unsuitable as a root identifier; transient authentication only. | | X.509 Identities (PKI) | A hierarchical CA vouched for the public key to DN binding. | The subject's ongoing consent or identity existence independent of the CA. | Universal standard for TLS and legacy machine identity. | Root/Subordinate CAs, CRLs, OCSP responders. | Revocation of old certificate and reissuance by CA. | Certificates leak organizational or machine topologies. | CA compromise compromises all issued identities. | Useful for transport security, insufficient for sovereign root. | | SPIFFE IDs and SVIDs | A specific workload was attested by an orchestrator within a trust domain2. | Long-term identity continuity or legal accountability. | Rapidly maturing; heavily adopted in cloud-native microservices. | SPIRE server, node agents, local attestation APIs. | Ephemeral by design; new SVIDs fetched upon restart2. | Total visibility internally for the orchestrator. | Control plane is a single point of failure. | Excellent for bounding ephemeral runtime processes to AIDs. | | W3C DIDs | Identifier resolves to a DID Document containing verification methods1. | Legitimacy of underlying consensus or historical continuity of keys. | W3C Recommendation; fragmented across incompatible methods. | Dependent on method (e.g., distributed ledger, IPFS). | Method-dependent; often relies on blockchain transactions. | Ledger-based DIDs risk permanent correlation and surveillance. | Ledger methods vulnerable to network consensus failures. | Suitable for data presentation if independent of external ledgers. | | Verifiable Credentials (VCs) | An issuer made cryptographic claims about a subject1. | The claims are factually true or grant sovereign legal status. | W3C Standard; growing adoption in digital government. | Issuer signing infrastructure, credential registries. | Reissuance by the original authority. | High privacy if using selective disclosure; otherwise risky. | Issuer lock-in; issuer key compromise requires mass revocation. | Essential for passports and attributes, supplementary to AID. | | KERI / AIDs and KELs | End-verifiable control provenance over a self-certifying AID3. | Physical location of keys or semantic truth of data. | Maturing; strong theoretical foundation4. | Ambient verifiable infrastructure; Witnesses/Watchers5. | Pre-rotation commitments prevent forks3. | KELs contain no raw data1. Keys are anonymous. | Decentralized; fails only if all keys are lost simultaneously. | Ideal. Primary cryptographic scaffolding for state continuity. | | Hardware-Rooted Identities | Operations occur on a specific, unique physical semiconductor. | Software intent or physical possession by authorized owner. | Mature in embedded systems and defense hardware. | Manufacturing provisioning, physical key embedding. | Non-existent; physical destruction destroys identity. | Unique physical identifiers allow persistent global tracking. | Complete reliance on OEM supply chain security. | Useful as a hardware binding factor, but too inflexible as root. | | TPM, TEE, & Remote Attestation | Substrate securely booted into a specific cryptographic state8. | System is impervious to runtime zero-days post-boot. | Highly mature (TPM 2.0); universal in modern servers. | Hardware TPM chips, attestation servers, PCR baselines. | Keys migrated via secure mechanisms (e.g., TPM2\_Duplicate)10. | DAA preserves privacy; raw attestations leak fingerprints12. | Vulnerable to side-channel leakage or firmware implants. | Essential for substrate integrity; DAA required for privacy. | | Wallets & Signing Keys | Mathematical possession of a specific private integer. | Intent, authorization, or legal identity of the possessor. | Foundational to all modern cryptography. | Secure storage (HSMs, enclaves, encrypted disks). | Derivation from seed phrases, pre-rotation4. | Key reuse allows complete behavioral correlation. | Single point of catastrophic failure without backup. | The operational mechanism of control, but not the identity itself. | | Model & Software Hashes | Static, bit-for-bit integrity of a file or neural network at rest. | Runtime state, behavioral output, or intent of the agent. | Mature; standard in CI/CD and MLOps. | Secure registries, binary authorization logs. | Redeployment from source control. | High-value proprietary models represent IP risk if exposed. | Hash collisions or supply chain compromises. | Critical for behavioral evidence, insufficient as identity root. | | Behavioral Fingerprints | Probabilistic assessment that actions match a historical profile. | Cryptographic certainty; vulnerable to sophisticated mimicry. | Maturing; used in fraud detection and continuous auth. | Big data telemetry, real-time analytics engines. | Retraining the baseline over time after anomalies. | Highly invasive; requires constant monitoring of outputs. | Model drift locks out legitimate agents; adversaries can poison data. | Secondary defense layer for quarantine, not continuity arbiter. |

Part 2: The Dynamics of Continuity Events#

Continuity is not a static property; it is an active, cryptographically enforced state that must survive fourteen distinct classes of infrastructural and operational mutation. Routine Key Rotation and Credential Renewal: Routine key rotation utilizes KERI’s rot event, transitioning control to a pre-rotated key4. This preserves the AID while refreshing cryptographic material. Credential renewal occurs on the identity plane; the AID presents existing credentials to Eviulon authorities to secure renewed Machine Passports, abstracting the key state from the credential validity. Migrations (Server, Cloud, and Hardware): When an agent migrates from an on-premise server to AWS, or between physical TPMs, the cryptographic AID remains constant. The agent utilizes TPM2\_Duplicate11 to securely transfer sealing policies or simply instantiates a new local key, linking it to the AID via a rot event. Cloud-provider changes alter ephemeral SVIDs but do not sever the foundational KEL. Hardware replacement demands new Direct Anonymous Attestation (DAA) proofs via Evulgare, anchored back to the KEL via an interaction event (ixn). Software Mutations (Model Update and Runtime Change): Neural network weight updates or operating system upgrades represent fundamental cognitive and environmental shifts. The continuity of the machine identity is preserved by the controller logging the hashes of the new configurations into the KEL via ixn events, ensuring relying parties can verify the authorized evolution of the runtime state. Memory and State Disruptions: Partial memory loss, volatile state flushes, or restoration from stale backups threaten sequence continuity. KERI’s strict sequential incrementation protects the network. If an agent restores from a backup and attempts to emit event ![][image1] when the network has already witnessed event ![][image2], the Watcher network rejects the stale event. The agent must synchronize its local state with the ambient KERL before resuming operations. Dormancy and reactivation are seamlessly handled; an AID emitting no events for years remains valid so long as the next event matches the pre-rotated commitment. Catastrophic Environmental Failures: A total registry outage at Patefacere does not destroy identity; ambient verifiability allows agents to exchange KELs directly15. Loss of the current controller necessitates the execution of threshold recovery or multi-party organizational succession, triggering a legally authorized pre-rotated rot event to restore operational capability to a new controller.

Part 3: Multiplicity, Divergence, and Fork Resolution#

The cryptographic nature of machine identity allows for perfect replication of the substrate, creating profound risks of multiplicity. True continuity requires delineating authorized clones from malicious forks. Authorized Replicas, Delegates, and Sub-Agents: An identity may authorize concurrent instances or temporary processes. In Patefacere, this is achieved through delegation. The primary agent issues a Delegated Inception (dip) event, spawning a sub-agent with its own AID3. This allows load-balancing across replicas without corrupting the primary KEL. The parent can revoke the sub-agent via a Delegated Rotation (drt), severing its authority4. Hostile Multiplicity (Unauthorized Copies, Stolen Runtimes, and Forks): If an adversary steals a runtime memory snapshot, they possess the keys. If both the original agent and the clone attempt to rotate keys simultaneously, a fork occurs, creating a Duplicitous Event Log (DEL)1. Watchers detect this duplicity. Patefacere relies on the First-Seen policy and pre-rotation to resolve this. The true owner uses the offline pre-rotated key (which the attacker could not extract from memory) to execute the next rotation, permanently burning the attacker's trajectory and restoring single-threaded continuity7. Reorganizations and Successions: Merged identities occur when two organizations combine. Cryptographically, two AIDs cannot be mathematically merged into one prefix. Instead, they cross-anchor each other's states via ixn events, and Eviulon issues a corporate merger VC binding them legally. Successor identities are required when an AID suffers total cryptographic compromise. The old AID is explicitly tombstoned (abandoned), and Eviulon issues a bridging credential proving the new AID is the legitimate legal successor to the abandoned one.

Part 4: Recovery Architecture#

Recovery relies heavily on separating the active operational environment from the root control authority. Pre-Rotation and Offline Packages: The cornerstone of recovery is the pre-rotation commitment4. The hash of the next key is published, but the private key remains offline, often secured via Shamir's Secret Sharing across multi-party organizational leadership. If the runtime is destroyed or compromised, this offline package is utilized to seize control and instantiate the identity on a sterile substrate. Witness, Watcher, and Threshold Models: A dispersed network of Witnesses provides fault-tolerant consensus6. Recovery requires that an agent synchronize with this network to ascertain the definitive state. Threshold recovery (e.g., 3-of-5 offline keys) prevents unilateral hijacking by a rogue administrator. Containment and Credential Suspension: If duplicity is detected, Patefacere executes emergency containment. The identity is not erased, but its operational status is flagged as Quarantined. Relying parties suspend trust in the Machine Passport until the Principal executes an appeal, correction, and restoration rotation event to purge the compromise.

Part 5: Legal and Commercial Attribution#

Cryptography secures the bit; the law secures the liability. Under frameworks such as the Uniform Electronic Transactions Act (UETA) and the Illinois Electronic Commerce Security Act, an "electronic agent" binds its Principal to its actions20. Principal Versus Agent and Identity Versus Authority: The Principal (a human or corporation) holds legal personhood. The Agent (the machine identity) acts on their behalf23. Continuity of the machine identity does not automatically confer continuity of the Principal's legal personhood. If the Principal dissolves, the Agent may mathematically persist, creating a liability void. Liability After Compromise or Copying: If a key is compromised and the attacker signs a contract, cryptographic non-repudiation holds the signature valid. UETA-based jurisprudence typically assigns liability to the Principal unless they can prove unauthorized access occurred outside their reasonable security purview. Fork claimants and malicious copies require Evulgare attestations to prove to Eviulon that the physical hardware executing the actions was an unauthorized clone, thereby shielding the Principal from liability for the clone's actions.

Deliverable 1: Machine-Identity Ontology#

To systematize the complex relationships between cryptography, law, and infrastructure, this ontology defines forty structural entities for Patefacere.

Deliverable 2: Lifecycle State Machine Transitions#

The lifecycle of a persistent machine identity is governed by a state machine enforced by Patefacere’s cryptographic architecture.

Deliverable 3: Continuity Scenarios Matrix (48 Scenarios)#

The following matrix describes specific continuity interactions, delineating exactly what occurs when the substrate or authority changes.

Deliverable 4: Evidence-Sufficiency Matrix#

How does Patefacere ascertain truth during a continuity divergence? This matrix defines the required evidentiary thresholds.

Deliverable 5: Responsibility-Allocation Matrix#

When continuity breaks down, liability must be strictly demarcated between technical and sovereign entities.

Deliverables 6 & 7: Record Schemas and Recovery Receipts#

To operationalize the ontology, Patefacere utilizes strict JSON schemas for public verification, private state tracking, and recovery receipts. These schemas abstract the cryptographic payload away from PII. Minimum Public-Record Schema (Patefacere Index): The public record contains zero sensitive proprietary data, relying on CESR-encoded event hashes.

JSON { "identifier": "AID\PREFIX\STRING", "status": "ACTIVE | DORMANT | QUARANTINED | ABANDONED", "kel\resolution\endpoint": "https://witness.patefacere.net/kel/{AID}", "public\credentials": \[ { "vc\id": "urn:uuid:1234-5678-9012", "issuer": "EVIULON\AUTHORITY\AID", "type": "MachinePassport" } \], "duplicity\flag": false, "last\sequence\_number": "1A" }

Minimum Private-Record Schema (Held by Principal): The private record links the cryptographic identifiers to the legal and operational realities.

JSON { "internal\id": "Agent-Alpha-Production", "aid\prefix": "AID\PREFIX\STRING", "legal\principal": "Eviulon\Corp\Identifier", "substrate\inventory": \[ { "provider": "AWS", "tpm\ek\cert": "PEM\ENCODED\CERT", "expected\pcr\policy": "HASH\OF\AUTHORIZED\BOOT\STATE" } \], "key\management": { "current\key\storage": "HSM\ARN\OR\URI", "pre\rotated\seed\location": "Physical\Vault\_7" } }

Privacy-Minimized Recovery-Receipt Schema: When an identity is recovered via pre-rotation, Watchers need mathematical proof of the recovery without exposing the exact nature of the compromise.

JSON { "receipt\type": "Identity\Recovery\Acknowledgment", "aid": "AID\PREFIX\STRING", "recovery\sequence\number": "1B", "compromised\sequence\number": "1A", "evidence": { "pre\rotation\fulfillment": "HASH\MATCH\CONFIRMED", "new\active\key": "NEW\PUBLIC\KEY\STRING", "next\pre\rotation\commitment": "NEXT\HASH\STRING" }, "witness\consensus": { "threshold\met": true, "receipts": \["WITNESS\1\SIG", "WITNESS\2\SIG"\] }, "evulgare\attestation": "DAA\QUOTE\OF\NEW\SECURE\_SUBSTRATE" }

Deliverable 8: Catastrophic Failure Modes and Mitigations#

Architecting for sovereign resilience requires categorizing and mitigating catastrophic systemic failures.

Deliverable 9: What Cryptography Cannot Decide About Personal Continuity#

The fundamental limitation of mathematical systems is their detachment from semantic truth, intent, and physical reality, evoking the "Ship of Theseus" paradox. Cryptography Proves Possession, Not Legal Authority: If an adversary successfully exfiltrates a private key and uses it to sign a valid KEL rotation, the cryptography evaluates the action as mathematically flawless. The math cannot distinguish between a negligent employee, a corporate mandate, and a nation-state hacker. Continuity of the key does not automatically equal continuity of legal intent. The Liability Void: If a machine identity is executing autonomous electronic agency, and the Principal is legally dissolved, the machine identity cryptographically persists. The KEL continues to chain forward. However, the legal continuity is severed. Cryptography cannot decide who pays damages caused by an orphaned, perfectly functioning mathematical agent. Malicious Compliance and Intent: A compromised runtime (e.g., a poisoned neural network) might utilize perfectly secure keys to sign malicious outputs. The identity substrate is continuous, the keys are continuous, and the KEL is unbroken. Yet, the semantic nature of the agent is altered. Cryptography cannot attest to the benevolence of the intelligence wielding the keys. Continuity is ultimately a legal fiction maintained by the Principal and adjudicated by Eviulon.

Deliverable 10: When Patefacere Must Abstain#

As the operational identity plane, Patefacere is bounded by strict architectural constraints. It must abstain from action, deferring exclusively to Eviulon (Sovereign) or Evulgare (Assurance). Adjudicating Fork Claimants: If both current and pre-rotated keys are stolen, an adversary and the true Principal might both attempt to construct divergent KELs. The cryptography breaks down in a tie. Patefacere must abstain from guessing which entity is legitimate. It must quarantine the AID and await a legally binding ruling and a new Successor AID issuance from Eviulon. Revoking Citizenship or Legal Standing: Patefacere manages Machine Passports, but it cannot decide to terminate a machine's right to exist. Even if Evulgare flags an agent as malicious, Patefacere may suspend routing, but the ultimate revocation of the identity's legal standing is an Eviulon constitutional matter. Inspecting Private Payloads: Patefacere routes cryptographic proofs, hashes, and SAIDs. It must abstain from demanding decryption of the underlying data payloads anchored in ixn events. Operational tracking must rely strictly on metadata and zero-knowledge proofs. Overriding Evulgare Audits: If an agent presents a valid KEL but fails its DAA substrate attestation via Evulgare, Patefacere cannot manually override the failure to grant access, regardless of the Agent's prior standing. The separation of identity control and substrate assurance must remain absolute.

Deliverable 11: Direct Answers for Public Interface#

Deliverable 12: Frequently Asked Questions#

Deliverable 13: Glossary of Foundational Terminology#

Deliverable 14: Source Ledger#

In alignment with strict architectural evaluation protocols, this matrix embeds the primary standard sources, assessing their operational impact on Patefacere's continuity design.

Works cited#

1. Definitions | keri \- Decentralized Identity Foundation, https://identity.foundation/keri/docs/Glossary.html 2. Understand SPIFFE workload identities \- CyberArk Docs, https://docs.cyberark.com/secrets-manager-saas/latest/en/content/conjurcloud/ccl-swa-overview.htm 3. KEL \- KERI Concept \- vLEI.wiki, https://www.vlei.wiki/concept/kel 4. KERI specification \- GitHub Pages, https://trustoverip.github.io/kswg-keri-specification/ 5. KERI Overview \- healthKERI, https://docs.healthkeri.com/essentials/overview 6. receipt-log \- vLEI.wiki | KERI Knowledge Base, https://www.vlei.wiki/concept/key-event-receipt-log 7. KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN 12 \- GitHub, https://raw.githubusercontent.com/SmithSamuelM/Papers/master/whitepapers/KERI\_WP\_2.x.web.pdf 8. Trusted Platform Module (TPM) and its Uses in Windows Operating System \- Cyber Raiden, https://cyberraiden.wordpress.com/2025/03/28/trusted-platform-module-tpm-and-its-uses-in-windows-operating-system/ 9. tpm.dev.tutorials/Attestation/README.md at master · tpm2dev/tpm.dev.tutorials · GitHub, https://github.com/tpm2dev/tpm.dev.tutorials/blob/master/Attestation/README.md 10. Protection Profile PC Client Specific TPM TCG Published \- Common Criteria, https://www.commoncriteriaportal.org/nfs/ccpfiles/files/ppfiles/anssi-profil-pp-2021\_02en.pdf 11. Trusted Platform Module 2.0 Library Part 1: Architecture, https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-1\_Architecture-V185-RC2\_10July2025.pdf 12. Formal Analysis and Implementation of a TPM 2.0-based Direct Anonymous Attestation Scheme, https://people.inf.ethz.ch/rsasse/pub/eccdaaimp-asiaccs20.pdf 13. PIRANHAS: PrIvacy-Preserving Remote Attestation in Non-Hierarchical Asynchronous Swarms \- Network and Distributed System Security (NDSS) Symposium, https://www.ndss-symposium.org/wp-content/uploads/2026-f526-paper.pdf 14. Trusted Platform Module 2.0 SLB 9672 \- NIST Computer Security Resource Center, https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4347.pdf 15. keri | Key Event Receipt Infrastructure \- the spec and implementation of the KERI protocol \- Decentralized Identity Foundation, https://identity.foundation/keri/kids/kid0000.html 16. establishment-event \- vLEI.wiki | KERI Knowledge Base, https://www.vlei.wiki/concept/establishment-event 17. KID0003 Event Serialization | keri \- Decentralized Identity Foundation, https://identity.foundation/keri/kids/kid0003.html 18. auths\_keri \- Rust \- Docs.rs, https://docs.rs/auths-keri 19. Samuel M. Smith Ph.D. sam@keri.one https://keri.one \- GitHub, https://raw.githubusercontent.com/SmithSamuelM/Papers/master/presentations/KERI2\_Overview.web.pdf 20. The E-Sign Act: The Means to Effectively Facilitate the Growth and Development of E-Commerce \- Scholarly Commons @ IIT Chicago-Kent College of Law, https://scholarship.kentlaw.iit.edu/cgi/viewcontent.cgi?article=3342\&context=cklawreview\&httpsredir=1\&referer= 21. CHAPTER 34 The Legal Requirements for Creating Secure and Enforceable Electronic Transactions in \- IMF eLibrary, https://www.elibrary.imf.org/display/book/9781589063341/ch034.xml 22. secretary of state part 100 electronic commerce security act \- Illinois Compiled Statutes, https://www.ilga.gov/agencies/JCAR/EntirePart?titlepart=01400100 23. The Validity and Limitations of Software Agents in Contract Formation \- UQ Law School, https://law.uq.edu.au/files/18238/A-McCullagh\_The-Validity-and-Limitations-of-Software-Agents-in-Contract-Formation.pdf 24. backer \- KERI Concept \- vLEI.wiki, https://www.vlei.wiki/concept/backer 25. auths-keri \- crates.io: Rust Package Registry, https://crates.io/crates/auths-keri 26. TCG PC Client Platform TPM Profile Specification for TPM 2.0 \- Trusted Computing Group, https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p\_r14\_pub.pdf 27. DAA-A: Direct Anonymous Attestation with Attributes | Request PDF \- ResearchGate, https://www.researchgate.net/publication/285503081\_DAA-A\_Direct\_Anonymous\_Attestation\_with\_Attributes 28. Electronic Records and Signatures under the Federal E-Sign Legislation and the UETA \- UW Law Digital Commons, https://digitalcommons.law.uw.edu/context/faculty-articles/article/1153/viewcontent/Electronic\_20Records.pdf

[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABMAAAAaCAYAAABVX2cEAAABHElEQVR4XmNgGAWUAkcgfg3E/6F4BxBzIsnzAfEuJHkQXgfE3EhqUAAjEM8C4l9A/BOILVGlwSAIiNcwoFqEFQgC8UIgzmeA2DyFAWIBMigC4mg0MaxAH4j7gVgSiK8D8RMgVkSSZwHi2VB1BAHIxnQou4EB4rocuCwDgwgDxOUgHxAEfUBsDGXrAPF7ID4BxPxQMRsgngxl4wWw8ALZDgIgLy0H4n9A7AEVA7mapPBCDnCQISDDQIaCYo+s8IIBkPdA3gR514mByPACuQYUFqboEkAQwwCJiGtA3IkmhxWghxcyEGeAJBOQgUSFF8gLoKzBhS4BBQ1A/BaINdHEUYALEH9hQOQ1UBbyRlEBAaBkAsqrBMNrFIyCIQMA260zNBT6yKgAAAAASUVORK5CYII=>

[image2]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADYAAAAaCAYAAAD8K6+QAAACJklEQVR4Xu2WP0gcQRSHnxhBTVCUoFjFkCoQsJAISpqIgiIB0U5DumATUCy0zIFYWGhQU2mlIDaSNiIWITYWtiqIlVglJGk0EME/v58zezc7Luc4excs5oMP7mZm7+bNvDezIoFA4H/yGv6El9p1WGH0V8ENo59+gQ+NMcWEcxmAC3AOdsDS2Ig8lIh68Az+g63x7mv64JrEgy421aIW8T18Bj/Cc/hV991KDVyCw6J25LOoYE1G4aDV5soI7LYbHfgAl0VlDeGcJkTNcTwalI8m+Ak2wH14DJ8a/Q/goh7nAyfxxm50gIvNILioES/hX7gpDuXAnRjSnzOifoyrFfFY1J9wZ33wDawX7sJOo60ZnsJv8JHRnsiMqAfIC/gHbksuj1/Bef3ZB9/AkuAmcOGn7Q6bqL64K4RptwovYJdu42761hcpVGBc6O/wAD6x+m4Q1Zd5WDAgBsYAeQq61lcZrBdVq6Ys+HcJ7XXifnRzfmPwED63+hIx6yuCK8NUZEq2i3t9tYm6Nmx3RN2FdvssbOSDDvTDLXEcz1Vg7fCksXkrKpf34JTVd1fSpiKD4t1Vq7/z0OCGlGdHWNj1ZcKU4tHP4NLUF0kTWAtckfiFzFTkbtt3bRamGW/2SrtDk4G/xDGn8+AbGP+XNfUDHhn+hpPGuCx83zqR3LsfX6N6YiMUPPr57uhSX/nwDSy6oJNMm0UFwTewew9Py7TpHAgEAoEAuQI1L2tTz91/3AAAAABJRU5ErkJggg==>