Principal Authorization for Autonomous Agents: Delegation, Exact-Step Consent, Succession, Revocation, and Receipt Lineage for Patefacere

Full report

On this page

The integration of autonomous software agents into high-stakes commercial, civic, and legal environments represents a paradigm shift that severely tests traditional agency law and cryptographic authorization structures. The legal framework surrounding these entities relies heavily on the Restatement (Third) of Agency, which defines authority through the manifestations of a principal to third parties1. Within the structural framework of Eviulon—which defines overarching civic and constitutional authority—Patefacere operates as an exact, immutable recording and verification layer. Drawing from its etymological root, patefacere (to open, disclose, or reveal), the infrastructure exists purely to record the exact lineage of authority, delegation, receipts, expiry, and revocation3. A critical architectural mandate is that Patefacere is strictly an operational recorder. It does not possess the capacity to invent a principal's authority, adjudicate equity, or manifest an Eviulon legal decision. The system simply maps cryptographic proofs of state to legal intent, relying on statutes like the Uniform Electronic Transactions Act (UETA) and the Electronic Signatures in Global and National Commerce Act (E-SIGN) to ensure that the autonomous actions of an electronic agent are legally attributable to the principal to be bound5.

The Jurisprudence of Machine Agency

The legal standing of electronic agents fundamentally relies on attribution rules that bind a human or corporate principal to the deterministic acts of an autonomous algorithm. UETA Section 14 and E-SIGN Section 101 establish that a contract cannot be denied legal effect solely because it was formed by the interaction of electronic agents, even in instances where no human was aware of or reviewed the specific actions6. However, attribution is not automatic. The actions of the electronic agent must be legally attributable to the principal. This is frequently demonstrated by the efficacy of applied security procedures, such as cryptographic signatures, mutual TLS (mTLS), or secure access tokens6. Under common law principles, when a principal deploys an autonomous agent, they create a manifestation to third parties that the agent possesses the authority to act, thereby invoking the doctrine of apparent authority1. Actual authority is established when a principal explicitly grants an agent the power to alter their legal relations. In the context of Patefacere, this is encoded via cryptographically signed configuration files and programmable caveats. Apparent authority arises from the reasonable belief of a third party, which must be traceable directly to the principal's manifestations1. If an enterprise deploys an agent without exact-step gating, counterparties may reasonably rely on the agent's commitments. Inherent agency power protects these third parties when an agent commits an ultra vires act—an action beyond its programmed mandate but within the customary domain of such an agent. Should an agent exceed its authority, the principal may engage in ratification, retroactively affirming the unauthorized machine transaction and assuming legal liability2. A critical distinction must be drawn between human-managed and independently authorized machine agents. A human-managed agent functions as a conduit for synchronous human intent. In contrast, an independently authorized machine agent operates asynchronously based on pre-computed policies and dynamic environment evaluations11. The transition from human-managed to independent requires explicit delegation. Under Patefacere's strict operational rules, a human-managed agent may never autonomously change its civic status, issue itself root credentials, create its own principal authority, or accept new legal obligations without exact, step-by-step authorization.

Corporate Governance, Succession, and State Volatility

Corporate authority is inherently volatile, particularly during organizational transformations such as mergers, acquisitions, bankruptcies, and dissolutions. In corporate governance, under statutes like the Delaware General Corporation Law (DGCL) Section 141(a), the management of a corporation is vested in its board of directors13. Corporate officers and their deployed electronic agents derive their authority strictly from the board. Recent amendments, such as DGCL Section 122(18), permit corporations to enter into stockholder agreements regarding future actions, but these do not override the requirement that delegated electronic agents operate strictly within their authorized limits14. When organizational changes occur, the authority delegated to electronic agents can evaporate instantly. Under DGCL Section 271, a corporation may sell substantially all its assets only with stockholder approval, meaning an autonomous agent cannot independently execute such a transaction15. In scenarios involving deadlock or insolvency, DGCL Sections 226 and 291 empower the Court of Chancery to appoint a custodian or receiver16. The appointment of a receiver instantly displaces the board's decision-making authority16. Any electronic agent previously authorized by that board loses its actual authority the moment the court order is signed. During corporate dissolution, a corporation continues to exist solely for the purpose of winding down. DGCL Section 275 dictates that the registered agent's authority terminates upon the effectiveness of the certificate of dissolution, fundamentally altering how the corporation interacts with the legal system17. This highlights the critical dichotomy between signer-key freshness and office succession: a cryptographic signature only proves that a specific key was utilized; it does not prove that the human or entity controlling the key still holds the legal office required to bind the principal.

Exact-Step Consent and the Boundaries of Machine Authority

Exact-step authorization mandates that broad programmatic permissions do not imply subsequent phase approvals. In the Patefacere ecosystem, this is a non-negotiable architectural constraint:

• Research authorization does not authorize a pilot.
• Pilot authorization does not authorize Patefacere adoption.
• Patefacere authorization does not authorize citizenship preparation.
• Preparation does not authorize submission.
• Submission authorization does not imply admission.

High-risk action gating demands that transaction value, legal exposure, or data privacy risks trigger mandatory human-in-the-loop checkpoints1. Authorization must be tightly bounded by the principal through programmatic caveats defining scope, purpose, monetary limits, rate limits, geographic constraints, jurisdictional boundaries, and temporal limits19. Emergency delegation protocols may allow for rapid authority transfer during crises, but these must possess automatic, unalterable expiry limits to prevent temporary powers from becoming permanent. Relying parties interacting with an agent must verify authority through Patefacere. If verification fails due to a revocation race or corporate dissolution, the relying party must abstain from the transaction to avoid assuming unratified liabilities.

Cryptographic Architecture of Delegation and Verification

Standard OAuth 2.0 is insufficient for complex, decentralized autonomous delegation due to its reliance on centralized authorization servers and static client registration20. Modern Identity and Access Management (IAM) requires advanced protocols. The Grant Negotiation and Authorization Protocol (GNAP), defined in RFC 9635 and 9767, separates the Requesting Party from the Resource Owner, allowing dynamic negotiation of multiple access tokens without prior client registration21. For decentralized, proof-carrying authorization, Macaroons provide bearer credentials that support monotonic attenuation through chained HMACs. A principal can append first-party caveats (e.g., time limits) and third-party caveats (requiring external discharge macaroons)19. Similarly, User Controlled Authorization Networks (UCAN) allow offline, chained delegation using public key infrastructure29. To prevent token theft, mechanisms like Demonstrating Proof-of-Possession (DPoP) bind tokens to a client's private key, utilizing nonces to prevent replay attacks30. To ensure transaction integrity, Patefacere mandates idempotency, sequence numbers, and predecessor chaining—where each action references the hash of the prior state30. These mechanisms resolve revocation races, where a principal revokes authority precisely as an agent attempts a transaction, by establishing an immutable chronological ledger of state changes.

Why a Valid Signature Is Not Enough

A pervasive fallacy in cryptographic systems design is the conflation of mathematical possession with legal authority. A valid digital signature strictly proves that a specific mathematical operation was executed using a discrete private key corresponding to a known public key. It does not, and architecturally cannot, prove current organizational authority, ongoing fiduciary compliance, or permission for a specific, exact-step act. Consider a scenario where a corporate officer is terminated with cause. The enterprise IAM system may sever their access to central servers, but the officer may still possess a locally stored private key on a hardware security module. If that terminated officer subsequently signs an electronic contract on behalf of the corporation, the cryptographic math remains flawless. The signature is mathematically valid. Yet, the legal authority is entirely void. The act is ultra vires. Similarly, when a Delaware Court of Chancery appoints a receiver under DGCL Section 29116, the board of directors is legally displaced. The directors' cryptographic keys are not erased from existence, nor do the mathematics of elliptic curve cryptography suddenly fail. However, their capacity to bind the principal evaporates the millisecond the receivership order is signed. If an autonomous agent relies solely on the cryptographic validation of a displaced board member's signature to execute a high-frequency trade three hours after receivership, the agent is acting without actual authority. Therefore, Patefacere architecture fundamentally divorces key validity from state validity. A valid signature is merely the initial gate. It must be checked against continuous, external state assertions: Is the signer still in the designated office? Has the corporation dissolved under DGCL 275? Is the specific act authorized by an exact-step delegation, or is it an unauthorized escalation? A valid signature proves who spoke; it never proves they still have the legal right to speak.

When the Agent Must Ask Again

An autonomous electronic agent operates strictly within the confines of its defined cryptographic mandate. It possesses zero inherent legal capacity to autonomously expand its scope, context, or legal exposure. Consequently, there are distinct boundaries where the agent must halt execution, suspend its state, and explicitly ask the principal for new authorization. This is the operationalization of exact-step authorization. An agent must ask again when crossing phase boundaries. Because research authorization does not authorize a pilot, an agent conducting analytical feasibility cannot autonomously begin executing test transactions in a live environment. When a pilot concludes, the agent must ask again before initiating Patefacere adoption. Furthermore, preparing civic or legal submissions does not authorize the final binding submission of those documents, and authorization to submit absolutely does not imply admission or final acceptance by a sovereign entity. An agent must also ask again when its operational context shifts unexpectedly. If an agent is authorized to negotiate supply contracts in Illinois under specific UETA exemptions6, but the counterparty attempts to shift the governing jurisdiction to Delaware, the agent must halt. If a transaction value exceeds a predefined monetary caveat, or if an environmental variable triggers a high-risk categorization (e.g., processing sensitive personal data requiring a human-in-the-loop checkpoint)1, the agent cannot rely on its original baseline authority. It cannot assume that a principal who authorized a $50,000 transaction implicitly authorizes a $50,001 transaction. The agent must prompt the principal, presenting the exact cryptographic context of the new step, and wait for explicit, chained cryptographic consent.

When Patefacere Must Refuse to Decide

Patefacere is an operational recorder—an immutable ledger of civic and constitutional authority tracing as defined by Eviulon. It is not a court of equity. It cannot adjudicate intent, it cannot weigh the moral balance of a corporate dispute, and it cannot invent an Eviulon legal decision. Therefore, Patefacere must mathematically and programmatically refuse to decide when presented with unresolvable legal paradoxes or cryptographic deadlocks. When a corporation experiences a severe internal fracture—such as a divided board of directors resulting in a deadlock requiring a custodian under DGCL Section 22616—Patefacere may receive conflicting directives. Director A's authorized agent attempts to revoke Director B's agent, while Director B's agent simultaneously attempts to liquidate assets. Both agents possess mathematically valid signatures traced back to the same corporate root. Patefacere cannot look beyond the cryptography to determine which director is acting in the "best interest" of the corporation. It must record both assertions, register the conflict, and categorically refuse to validate either agent's authority to relying parties. Patefacere must also refuse to decide when chronological certainty fails. In a highly contested revocation race where an offline relying party accepts a delegated token, and a revocation is broadcast globally in the exact same temporal window without clear predecessor chaining resolution, Patefacere cannot invent a timeline. It must record the collision and output a state of "Indeterminate Authority," forcing human arbitration or judicial intervention. Patefacere's power lies in its epistemological humility: by refusing to invent truth, it preserves the absolute integrity of the truth it does record.

1. Authority Ontology

2. 20-State Principal-Authorization Lifecycle

3. 20-State Delegation Lifecycle

4. 64 Detailed Authority Scenarios

5. 32 Revocation-Race Scenarios

6. 24 Officer-Succession and Organizational-Change Scenarios

7. Field-Complete Principal-Authorization Receipt Schema

The following JSON schema defines the immutable receipt that Patefacere records upon a valid principal authorization, cementing the exact-step lineage and cryptographic bounds.

JSON { "$schema": "https://patefacere.eviulon.org/schemas/receipt/v1", "type": "object", "properties": { "receipt\_id": { "type": "string", "description": "UUIDv7 ensuring strict chronological sortability and ledger placement." }, "timestamp": { "type": "string", "format": "date-time", "description": "ISO-8601 strict timestamp of recording by the Patefacere system." }, "principal": { "type": "object", "properties": { "did": { "type": "string", "description": "Decentralized Identifier of the Principal." }, "legal\_entity\_id": { "type": "string", "description": "LEI or state corporate registry number." }, "office\_held": { "type": "string", "description": "Current corporate office (e.g., CEO, Director)." } }, "required": \["did", "legal\_entity\_id", "office\_held"\] }, "agent": { "type": "object", "properties": { "agent\_id": { "type": "string", "description": "Cryptographic Identifier of the autonomous agent." }, "agent\_type": { "type": "string", "enum": \["human-managed", "independent"\] } }, "required": \["agent\_id", "agent\_type"\] }, "authorization\_payload": { "type": "object", "properties": { "exact\_step\_phase": { "type": "string", "description": "Strict phase boundary (e.g., 'research', 'pilot', 'adoption')." }, "caveats": { "type": "array", "items": { "type": "string" }, "description": "Array of Macaroon-style first-party and third-party constraints." }, "monetary\_limit": { "type": "number", "description": "Hard financial cap for agent transactions." }, "jurisdiction": { "type": "string", "description": "Allowed legal jurisdictions (e.g., 'Delaware', 'Illinois')." }, "expiry": { "type": "string", "format": "date-time", "description": "Unalterable mathematical expiration timestamp." } }, "required": \["exact\_step\_phase", "caveats", "expiry"\] }, "cryptographic\_proof": { "type": "object", "properties": { "signature": { "type": "string", "description": "Ed25519 or ECDSA signature of the payload." }, "public\_key": { "type": "string", "description": "Public key matching the signature." }, "predecessor\_hash": { "type": "string", "description": "Hash of the prior Patefacere state for this entity, ensuring chronological integrity." } }, "required": \["signature", "public\_key", "predecessor\_hash"\] } }, "required": \["receipt\_id", "timestamp", "principal", "agent", "authorization\_payload", "cryptographic\_proof"\] }

8. Field-Complete Revocation and Correction Schema

This schema handles deliberate termination or UETA Section 14 error correction events32, ensuring a verifiable trail of rescinded authority.

JSON { "$schema": "https://patefacere.eviulon.org/schemas/revocation/v1", "type": "object", "properties": { "event\_id": { "type": "string", "description": "Unique identifier for this revocation or correction event." }, "timestamp": { "type": "string", "format": "date-time" }, "target\_receipt\_id": { "type": "string", "description": "The specific receipt\_id of the authorization being revoked or corrected." }, "action\_type": { "type": "string", "enum": \["revocation", "correction", "suspension", "legal\_void"\], "description": "'legal\_void' is used specifically for receivership or dissolution events." }, "reason\_code": { "type": "string", "description": "Standardized codes: e.g., 'UETA\_SEC\_14\_ERROR', 'DGCL\_291\_RECEIVERSHIP', 'EXACT\_STEP\_HALT'." }, "initiating\_party": { "type": "object", "properties": { "did": { "type": "string" }, "role": { "type": "string", "description": "Principal, Patefacere Admin, Enterprise IAM, or Court Appointee." } }, "required": \["did", "role"\] }, "cryptographic\_proof": { "type": "object", "properties": { "signature": { "type": "string" }, "predecessor\_hash": { "type": "string" } }, "required": \["signature", "predecessor\_hash"\] } }, "required": \["event\_id", "timestamp", "target\_receipt\_id", "action\_type", "reason\_code", "initiating\_party", "cryptographic\_proof"\] }

9. Field-Complete Delegation Schema

This schema maps the strict monotonic attenuation from a Principal to an Agent, and subsequently to a Sub-Agent, mirroring Macaroon and UCAN architecture.

JSON { "$schema": "https://patefacere.eviulon.org/schemas/delegation/v1", "type": "object", "properties": { "delegation\_id": { "type": "string" }, "root\_authorization\_id": { "type": "string", "description": "Points explicitly back to the original principal-authorization receipt." }, "delegator": { "type": "object", "properties": { "agent\_id": { "type": "string" }, "current\_state\_hash": { "type": "string" } }, "required": \["agent\_id"\] }, "delegatee": { "type": "object", "properties": { "sub\_agent\_id": { "type": "string" }, "intended\_purpose": { "type": "string" } }, "required": \["sub\_agent\_id"\] }, "attenuation\_caveats": { "type": "array", "items": { "type": "string" }, "description": "Additional monotonic restrictions appended to the root authority (cannot expand scope)." }, "delegation\_token": { "type": "string", "description": "The base64 encoded Macaroon, UCAN, or GNAP token representing the delegated state." } }, "required": \["delegation\_id", "root\_authorization\_id", "delegator", "delegatee", "attenuation\_caveats", "delegation\_token"\] }

10. Verification Algorithm

The following precise pseudocode details how Patefacere (or a Relying Party) verifies an agent's request. It ensures strict compliance with exact-step logic, cryptographic validity, and the critical check of legal office status. FUNCTION VerifyAgentAuthority(Request, AgentToken, PrincipalID, TargetService): // 1\. Basic Cryptographic Validation IF NOT VerifySignature(AgentToken.Signature, AgentToken.PublicKey): RETURN REJECT("Invalid Signature")

// 2\. Exact-Step Evaluation IF Request.Phase \!= AgentToken.ExactStepPhase: RETURN REJECT("Exact-Step Mismatch: Requested Phase not Authorized")

// 3\. Temporal Validation (Expiry) IF CurrentTime() \> AgentToken.Expiry: RETURN REJECT("Token Expired")

// 4\. Revocation Ledger Sync & Evaluation LatestLedger \= Patefacere.GetLatestState(PrincipalID) IF TargetService.IsOffline(): IF NOT IsWithinOfflineTolerance(TargetService.LastSync): RETURN REJECT("Offline CRL out of date") ELSE: IF LatestLedger.ContainsRevocation(AgentToken.ID): RETURN REJECT("Token Revoked")

// 5\. Office & Legal Validity Check (Why Signature Is Not Enough) PrincipalState \= Eviulon.GetLegalState(PrincipalID) IF PrincipalState.InReceivership \== TRUE OR PrincipalState.IsDissolved \== TRUE: RETURN REJECT("Legal Authority Voided: Corporate Governance Event (DGCL 291/275)") IF PrincipalState.Officer(AgentToken.IssuerKey).IsActive \== FALSE: RETURN REJECT("Legal Authority Voided: Signer No Longer In Office")

// 6\. Conflicting Directives Check IF LatestLedger.HasDeadlockOrConflict(PrincipalID): RETURN REFUSE\_TO\_DECIDE("Unresolvable Conflict Between Principals (e.g., DGCL 226)")

// 7\. Caveat Evaluation (Macaroons/UCAN) FOR EACH Caveat IN AgentToken.Caveats: IF IsFirstParty(Caveat): IF NOT EvaluateConstraint(Caveat, Request.Context): RETURN REJECT("First-Party Caveat Violated: " \+ Caveat.Rule) ELSE IF IsThirdParty(Caveat): DischargeToken \= Request.GetDischarge(Caveat.ID) IF NOT VerifyDischarge(DischargeToken, Caveat.VerifierKey): RETURN REJECT("Third-Party Caveat Violated: Missing or Invalid Discharge Token")

// 8\. Replay & Idempotency Prevention IF LatestLedger.HasNonce(Request.Nonce): RETURN REJECT("Replay Detected: Nonce Already Consumed") IF Request.SequenceNumber \<= LatestLedger.LastSequenceNumber: RETURN REJECT("Invalid Sequence Number: Must be Strictly Increasing")

// All Checks Pass RETURN APPROVED

END FUNCTION

11. Authorization Protocols Matrix

12. 40 FAQs

13. 25 Website-Ready Direct Answers

14. 60-Term Glossary

15. Primary-Source Research Ledger

Works cited

1. AI Agent Legal Liability: Who Pays When Your Autonomous Tool Binds Your Company, https://blog.promise.legal/ai-agent-legal-liability-contracting-authority/

2. AI as Agents (Chapter 11\) \- The Cambridge Handbook of Artificial Intelligence, https://www.cambridge.org/core/books/cambridge-handbook-of-artificial-intelligence/ai-as-agents/A15807BF655559096E806F462C5AB939

3. The coming community \- cooltexts, https://cooltexts.github.io/sources/agamben.pdf

4. Chapter Twenty-Five Infinitives; Indirect Statement \- The Official Wheelock's Latin Series Website, http://www.wheelockslatin.com/chapters/twentyfive/index.html

5. CONTRACTING IN THE AGE OF THE INTERNET OF THINGS: ARTICLE 2 OF THE UCC AND BEYOND \- Hofstra Law Review, https://www.hofstralawreview.org/wp-content/uploads/2017/01/CC.3.Elvy\_.pdf

6. Regulating Electronic Commerce, https://scholarship.law.gwu.edu/cgi/viewcontent.cgi?article=1820\&context=faculty\_publications

7. 15 U.S. Code § 7001 \- General rule of validity \- Law.Cornell.Edu, https://www.law.cornell.edu/uscode/text/15/7001

8. UNIFORM ELECTRONIC TRANSACTIONS ACT (1999), http://euro.ecom.cmu.edu/program/law/08-732/Transactions/ueta.pdf

9. BUSINESS TRANSACTIONS (815 ILCS 333/) Uniform Electronic Transactions Act. \- Illinois General Assembly \- \-, https://www.ilga.gov/Legislation/ILCS/Articles?ActID=4165\&ChapterID=67

10. UETA \- Clickwrap Enforceability at State Level \- ClickTerm, https://clickterm.com/legal-hub/ueta/

11. (PDF) Artificial Agents and the Contracting Problem: A Solution Via an Agency Analysis, https://www.researchgate.net/publication/228304132\_Artificial\_Agents\_and\_the\_Contracting\_Problem\_A\_Solution\_Via\_an\_Agency\_Analysis

12. ARTIFICIAL AGENTS AND THE CONTRACTING PROBLEM: A SOLUTION VIA AN AGENCY ANALYSIS \- University of Illinois Journal of Law, Technology, & Policy, https://illinoisjltp.com/file/88/Chopra.pdf

13. Board and Stockholder Resolutions Toolkit (DE Corporation) \- Practical Law, https://anzlaw.thomsonreuters.com/w-032-9594?transitionType=Default\&contextData=(sc.Default)

14. 2024 Amendments to the DGCL & Delaware's Alternative Entity Statutes, https://www.morrisnichols.com/insights-2024-amendments-to-the-dgcl-delawares-alternative-entity-statutes

15. Shareholder Approval Is Required Under Delaware Law to Sell All or Substantially All of an Insolvent and Failing Corporation's Assets | Business Vantage Point Blog, https://www.stradley.com/business-vantage-point-blog/shareholder-approval-is-required-under-delaware-law-to-sell-all-or-substantially-all-of-an-insolvent-and-failing-corporations-assets

16. Delaware Custodians, Receivers and Trustees (Oh My\!) \- Richards, Layton & Finger, https://www.rlf.com/wp-content/uploads/2022/03/Delaware-Custodians.pdf

17. Legislation Document \- Delaware General Assembly, https://legis.delaware.gov/json/BillDetail/GenerateHtmlDocument?legislationId=143065\&legislationTypeId=1\&docTypeId=2\&legislationName=HB353

18. February 2026 in Brief: Corporations, LLCs & Partnerships \- American Bar Association, https://www.americanbar.org/groups/business\_law/resources/business-law-today/2026-february/in-brief-corporations-llcs-partnerships/

19. Macaroons 101: Contextual Confinement | Evan Cordell, https://evancordell.com/posts/macaroons-101-contextual-confinement/

20. Grant Negotiation and Authorization Protocol (GNAP) \- Simon Willison's Weblog, https://simonwillison.net/2024/Oct/14/grant-negotiation-and-authorization-protocol-gnap/

21. GNAP Explained: Grant Negotiation & Authorization Protocol \- Frontegg, https://frontegg.com/blog/gnap

22. RFC 9635 \- Grant Negotiation and Authorization Protocol (GNAP) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9635

23. RFC 9767: Grant Negotiation and Authorization Protocol Resource Server Connections, https://www.rfc-editor.org/info/rfc9767/

24. What Is GNAP? A New Authorization Protocol Beyond OAuth2 \- FusionAuth, https://fusionauth.io/blog/gnap-next-gen-oauth

25. Cryptographic Security of Macaroon Authorization Credentials \- NYU Computer Science department, https://cs.nyu.edu/media/publications/TR2013-962.pdf

26. Macaroons in Depth: Advanced Authorization for Modern Applications \- DevOps.dev, https://blog.devops.dev/macaroons-in-depth-advanced-authorization-for-modern-applications-104b3a88502d

27. macarunes \- Rust \- Docs.rs, https://docs.rs/macarunes

28. GitHub \- rescrv/libmacaroons: Macaroons are flexible authorization credentials that support decentralized delegation, attenuation, and verification., https://github.com/rescrv/libmacaroons

29. ucan-wg/spec: User Controlled Authorization Network (UCAN) Specification \- GitHub, https://github.com/ucan-wg/spec

30. The DPoP Storage Paradox: Why Browser-Based Proof-of-Possession Remains an Unsolved Problem \- InfoQ, https://www.infoq.com/articles/dpop-key-storage-unsolved-problem/

31. State of Illinois 91st General Assembly Legislation, https://ilga.gov/documents/legislation/legisnet91/sbgroups/sb/910SB1309LV.html

32. Uniform Electronic Transactions Act \- Kansas City Real Estate Lawyer, https://kcrealestatelawyer.com/wp-content/uploads/2020/02/UNIFORM-ELECTRONIC-TRANSACTIONS-ACT.pdf

33. 102-0038.pdf \- Be it enacted by the People of the State of Illinois, represented in the General Assembly:, https://www.ilga.gov/documents/legislation/publicacts/102/PDF/102-0038.pdf

34. The Use of Electronic Agents Questioned Under Contractual Law: Suggested Solutions on a European American Level, 18 J. Marshall, https://repository.law.uic.edu/cgi/viewcontent.cgi?article=1184\&context=jitpl

35. Delaware Corporation Dissolution Guide: Steps & Requirements \- Inkle, https://www.inkle.ai/blog/delaware-corporation-dissolution

36. Electronic Signatures: Review and Analysis \- UKnowledge, https://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1003\&context=ktc\_technicalassistancereports