Electronic Transactions, Contracts and Digital Commerce

Introduction and Context

Digital commerce has changed the legal and operational meaning of a transaction. A customer may accept terms by selecting a button, an enterprise may conclude a software licence through an online portal, and a machine may initiate a transaction through an application programming interface (API). In each case, the central compliance questions remain familiar: Who are the parties? What was agreed? Was consent valid? Can the agreement be proved? What remedies exist if performance fails?

Electronic transactions are not legally unstructured transactions. They are transactions in which communication, evidence, identity, performance and risk are mediated by information systems. Consequently, IT professionals must understand both legal doctrine and system design. Contract wording alone is insufficient if the system cannot preserve evidence of acceptance, identify the contracting party, control access or demonstrate the applicable version of terms.

This chapter uses general legal principles and internationally common approaches. Electronic-transactions statutes, consumer laws, privacy rules, signature requirements and sector-specific regulations differ by jurisdiction. Organisations must therefore obtain jurisdiction-specific legal advice before relying on a particular electronic process.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the legal significance of electronic records and electronic signatures.
2. Distinguish clickwrap, browsewrap, shrinkwrap and negotiated online contracts.
3. Analyse formation, authority, evidence, incorporation of terms and jurisdiction.
4. Interpret important provisions in software, cloud and SaaS agreements.
5. Evaluate warranties, disclaimers, indemnities, limitation-of-liability clauses and service levels.
6. Apply consumer-protection and platform-governance principles to digital commerce.
7. Assess the legal and operational implications of smart contracts and automated transactions.
8. Design compliance controls that connect contractual obligations with IT architecture and governance.

1. Electronic Transactions as Legal Events

An electronic transaction is a transaction in which information is created, sent, received, stored or processed electronically. It may involve email, web forms, mobile applications, electronic data interchange, digital signatures, online payment systems, cloud platforms or machine-to-machine communication.

Three concepts should be separated:

• Electronic record: Information recorded or communicated in digital form.
• Electronic signature: An electronic mark, process or method used with the intention of signing.
• Digital signature: A cryptographic form of electronic signature using a private key and a corresponding public-key verification process.

A digital signature is therefore one type of electronic signature, not a synonym for every electronic signature. A typed name, a signature image, a biometric action, a one-time password confirmation and a cryptographic signature may all be treated differently under applicable law and evidence rules.

Most modern electronic-transactions frameworks are based on functional equivalence. They seek to prevent a record or signature from being denied legal effect merely because it is electronic. The practical questions are whether the method reliably identifies the person, indicates intention, preserves the record and supports later verification.

1.1 Functional equivalence

The principal functional requirements are:

Functional equivalence does not mean that every paper form can automatically be replaced. Certain documents may be excluded or subject to special rules, including wills, negotiable instruments, land transfers, family-law documents, powers of attorney or regulated financial instruments. The exclusion list depends on national law.

1.2 Electronic records and evidence

A record is valuable in litigation or an audit only when its authenticity and integrity can be explained. Useful evidence may include:

• the exact terms displayed at acceptance;
• the version number and effective date of those terms;
• the identity or account used by the accepting party;
• time stamps, time zone and server clock controls;
• the IP address and relevant device or session information;
• logs showing the acceptance event;
• the transaction identifier and payment record;
• evidence that the record was not altered;
• notices, confirmations and subsequent conduct.

A log is not automatically reliable merely because it exists. Access controls, clock synchronisation, retention policies, tamper resistance, segregation of duties and documented procedures strengthen evidential weight. Hashing can help detect changes to a file, but a hash by itself does not prove who created the file or agreed to its content.

2. Electronic Signatures and Digital Identity

2.1 Signature functions

A signature generally performs several functions:

1. Identification: associating an act with a person or organisation.
2. Authentication: providing confidence that the purported signer is the relevant actor.
3. Intention: showing approval, adoption or commitment.
4. Integrity: helping establish that the signed content has not changed.
5. Evidence: providing a record capable of later verification.

Different transactions require different levels of assurance. A low-value consumer purchase may use account credentials and a confirmation button. A high-value securities transaction may require a regulated trust service, strong authentication, certificate management and formal organisational authority.

2.2 Types of electronic signature

A basic electronic signature may be a typed name, scanned signature, tick box or click-to-accept action. Its legal sufficiency depends on context and the applicable statute.

An advanced electronic signature commonly requires that the signature be uniquely linked to and capable of identifying the signer, remain under the signer’s control, and be linked to the signed data so that later alteration is detectable. Exact legal requirements vary.

A qualified electronic signature generally relies on a qualified certificate and a regulated trust-service framework. In some jurisdictions it receives a legal presumption or is required for specified transactions.

The compliance decision should be risk-based. Relevant variables include transaction value, fraud exposure, repudiation risk, regulatory requirements, consumer vulnerability, cross-border enforceability and the cost of stronger authentication.

2.3 Digital signatures in technical terms

In a public-key system, the signer uses a private key to generate a signature over a message digest. A verifier uses the public key to check the signature. Conceptually:

where m is the message, H is a cryptographic hash function, and h is the resulting digest. The signature algorithm then signs h using the private key. The verifier checks the signature using the public key and independently computes the digest of the received message. If the values correspond, integrity and control of the private key are supported, subject to the security of the algorithm, certificate infrastructure and key management.

This process does not by itself prove that the signer understood the contract, had legal capacity or possessed authority to bind a company. Identity proofing, organisational authorisation and user-interface design remain necessary.

3. Formation of Online Contracts

A contract normally requires offer, acceptance, consideration or an equivalent legal basis, intention to create legal relations, capacity and legality. Electronic communication changes the medium, not the fundamental inquiry.

3.1 Offer and invitation to treat

A website catalogue is often an invitation for customers to make offers rather than a legal offer capable of automatic acceptance. The checkout process may constitute the customer’s offer, with the seller accepting through an order confirmation or dispatch. However, wording and jurisdiction matter. A system should clearly state when a contract is formed, particularly where inventory, pricing or fraud checks may cause rejection.

3.2 Clickwrap

In a clickwrap arrangement, the user is presented with terms and takes an affirmative action such as selecting “I agree.” Enforceability is strengthened when:

• the terms are displayed or directly linked;
• the link is conspicuous and readable;
• acceptance is separate from unrelated actions;
• the user cannot proceed without accepting;
• important exclusions or unusual terms are highlighted;
• a copy of the accepted terms is supplied;
• the system records the version, time and user identity.

A “sign-in-wrap” design links agreement to terms through a notice near a sign-in button. Its effectiveness depends on the clarity and prominence of the notice and the user’s reasonable notice of the terms.

3.3 Browsewrap and shrinkwrap

Browsewrap attempts to bind a user merely through use of a website, often with a footer link. It is vulnerable when users are not clearly informed that use constitutes acceptance. Courts may examine notice, prominence, repeat use and the overall interface.

Shrinkwrap terms are presented with packaged software, commonly stating that opening the package or using the software constitutes acceptance. Modern equivalents include installation-screen terms and licence prompts. The customer must have a meaningful opportunity to review and reject the terms; otherwise incorporation may be challenged.

3.4 Contracting by email and automated systems

Email can evidence offer, acceptance, authority and variation, but informal language may create ambiguity. Automated systems can generate binding communications where the parties have authorised the system. Organisations should establish rules for erroneous automated messages, duplicate orders, system outages and unauthorised credentials.

The electronic communications model often treats a message as dispatched when it leaves the sender’s control and received when it reaches the designated information system, but statutory rules differ. Contract terms should specify communication channels, notice addresses and effective times.

3.5 Incorporation and version control

A contract may incorporate external policies, acceptable-use rules, privacy notices, security schedules and service descriptions. Incorporation is safer when the documents are identified precisely, accessible before acceptance and connected to a stable version. A general statement that “all policies as amended from time to time apply” may be ineffective or commercially unfair if it permits unilateral alteration of material obligations without notice or consent.

A compliant platform should preserve:

• the accepted document and all incorporated documents;
• a cryptographic hash or equivalent integrity control;
• the effective date and version;
• the acceptance interface;
• records of later amendments and re-consent;
• the language and jurisdiction presented to the user.

4. Consumer Protection and Platform Terms

Digital consumers may face information asymmetry, dark patterns, hidden charges, forced continuity, difficult cancellation, unfair arbitration clauses, misleading endorsements and opaque ranking systems. Consumer law commonly addresses unfair terms, misleading conduct, cancellation rights, distance selling, automatic renewals, product safety, refunds and data practices.

4.1 Transparency and fairness

Terms should be intelligible, accessible and proportionate. A clause may be legally vulnerable if it creates a significant imbalance, contradicts the customer’s reasonable expectations or is concealed in a lengthy interface. Legal review should focus especially on:

• price, taxes and recurring charges;
• trial conversion and renewal;
• cancellation and refund processes;
• delivery, availability and geographic limits;
• data use and profiling;
• dispute resolution and governing law;
• liability exclusions and account suspension;
• content moderation and appeal rights.

A platform’s terms should be consistent with its actual interface, advertisements and customer-support practices. A company cannot reliably cure a misleading promise by placing contradictory language in small print.

4.2 Platform governance

Platforms often act as intermediaries among sellers, buyers, advertisers, creators and service providers. Their terms allocate responsibility for identity verification, prohibited content, intellectual property, payment settlement, fraud, moderation and account termination.

Important governance controls include:

• clear seller and platform identities;
• transparent ranking and advertising disclosures;
• complaint and appeal channels;
• records of moderation decisions;
• controls against counterfeit or unsafe goods;
• procedures for law-enforcement requests;
• accessible terms for different user groups;
• mechanisms for correcting inaccurate account information.

Platform terms should not be treated as a substitute for statutory compliance. Mandatory consumer, competition, privacy, employment and product-safety duties may apply regardless of contractual wording.

5. Software, SaaS and Cloud Agreements

Software agreements allocate rights in code, data, configuration, support, security and operational continuity. The legal form may be a licence, subscription, services agreement, click-through licence, enterprise agreement or a combination of documents.

5.1 Licence scope

A licence should specify whether it is exclusive or non-exclusive, transferable or non-transferable, perpetual or term-based, worldwide or restricted, and limited by users, devices, sites, transactions or processing capacity. It should identify permitted copies, development and testing environments, interfaces, backup use, reverse engineering, subcontracting and open-source components.

Ownership of the software normally remains with the licensor unless expressly transferred. The customer may own its data, configurations or generated outputs, but the agreement should define those categories and address the provider’s limited rights to process data for operation, security, analytics or service improvement.

5.2 SaaS allocation of responsibility

In SaaS, the provider controls much of the infrastructure, while the customer controls users, configuration and business use. A responsibility matrix should address:

5.3 Open-source and third-party dependencies

A commercial product may contain open-source software, APIs, models, hosting services or other dependencies. Compliance requires a software bill of materials where appropriate, licence review, vulnerability management, attribution, source-code obligations and a plan for unsupported components. Contractual warranties should not promise ownership or non-infringement more broadly than the provider can substantiate.

6. Warranties, Remedies and Risk Allocation

A warranty is a promise that a specified fact or performance condition is true. A representation may induce entry into a contract, while a condition may be central to performance; classification and remedies vary by law.

Common technology warranties concern authority, conformity to documentation, professional performance, malware controls, intellectual-property non-infringement, data protection and service availability. A warranty should state its scope, duration, exclusions, notice requirements and remedy.

A disclaimer attempts to exclude implied warranties, such as fitness for a particular purpose or merchantability, where law permits. Disclaimers may not defeat mandatory consumer guarantees, fraud claims, deliberate misconduct or statutory rights.

6.1 Limitation of liability

A limitation clause may:

• exclude indirect or consequential loss;
• cap aggregate liability at a fixed amount or fees paid;
• create higher caps for specified risks;
• exclude lost profits, revenue or data;
• preserve liability for fraud, death, bodily injury, confidentiality breach or intellectual-property infringement.

A single cap may be inappropriate where risks are asymmetric. For example, a modest subscription fee may not reasonably measure exposure arising from a serious data breach or infringement claim. A more defensible structure may use a general cap, super-cap categories and uncapped liabilities where legally required.

Courts may examine incorporation, clarity, bargaining power, reasonableness, statutory restrictions and the parties’ commercial purpose. IT managers should not accept a liability clause without comparing it with insurance, recovery costs, regulatory exposure and business criticality.

6.2 Indemnities

An indemnity allocates specified third-party or direct claims. It should identify covered claims, control of defence, settlement consent, cooperation, mitigation and exclusions. Typical technology indemnities cover intellectual-property infringement, personal injury, data incidents or violation of law. An indemnity is not automatically unlimited, and its interaction with the liability cap must be explicit.

7. Service Levels and Operational Enforceability

A service-level agreement (SLA) converts service expectations into measurable commitments. It may address availability, response time, resolution time, support hours, maintenance windows, recovery objectives and service credits.

Availability is commonly calculated as:

The formula assumes that “total agreed time” and “unavailable time” are defined consistently, that scheduled exclusions are removed according to the contract, and that measurement systems use a common time basis. For a 30-day month with 24-hour coverage, total agreed time is 720 hours. If unavailability is 43.2 minutes, equivalent to 0.72 hours, availability is:

This calculation does not determine whether the SLA has been breached unless the contract defines monitoring points, excluded events, rounding, partial outages and the applicable service level.

An SLA should distinguish service credits from damages. Credits may be the exclusive remedy, a price adjustment or merely one remedy among others. It should specify claim procedures, automatic application, reporting, dependencies and whether repeated failure triggers termination or a remediation plan.

8. Smart Contracts and Automated Transactions

A smart contract is code that performs, records or enforces transaction logic, often on a distributed ledger. It may be a complete legal contract, a mechanism for performance of a separate legal contract, or merely software that automates certain actions. Code is not automatically a legally complete agreement.

A legally robust arrangement separates:

1. the parties and their authority;
2. the legal terms and governing law;
3. the coded operational rules;
4. the data sources or oracles used by the code;
5. correction, suspension and dispute mechanisms;
6. treatment of coding errors, forks and network failure.

Smart contracts create distinctive risks. Immutable execution may continue despite fraud, mistake or changed circumstances. Oracle data may be inaccurate or manipulated. Private-key loss may make control impossible. A public ledger may conflict with confidentiality, deletion or data-localisation obligations. Automated payments can also create consumer-protection problems if cancellation is impossible.

A prudent design uses pause controls, upgrade governance, multisignature authorisation, independent code review, event logging, oracle validation and an emergency dispute process. These controls may reduce decentralisation or automation, but legal enforceability and operational resilience usually require some form of human governance.

9. Applied Case: Cloud-Based Retail Platform

Background

This illustrative case concerns Northstar Retail, a growing online retailer that adopts a SaaS order-management platform from CloudAxis. Customers place orders through a mobile application. CloudAxis hosts customer data, processes payments through a third party and updates the platform weekly.

Problem

Northstar accepts the provider’s online terms without downloading them. The terms incorporate a security policy “as amended from time to time.” The SLA promises 99.9% monthly availability but excludes maintenance, third-party failures and “events beyond reasonable control.” Liability is capped at fees paid during the preceding three months. After a faulty update, orders are duplicated for six hours. Northstar incurs refunds, lost sales and investigation costs. A customer also alleges that the checkout process concealed automatic renewal of a premium membership.

Analysis

The contract-formation record is weak if Northstar cannot prove which terms were accepted. The unilateral policy-change clause may be challenged if material changes were made without notice or re-consent. The SLA calculation requires precise definitions of measurement points and exclusions. The liability cap may be commercially inadequate for a business-critical service, although its enforceability depends on applicable law and negotiation context.

The duplicated orders raise questions about conformity to documentation, professional performance, incident response, change management and limitation-of-liability wording. The customer-facing renewal process raises consumer-transparency concerns independent of the SaaS dispute.

Approach and solution

Northstar should negotiate an enterprise agreement containing:

• version-controlled documents and a formal amendment process;
• a responsibility matrix for application, infrastructure, data and integrations;
• change-notice and rollback obligations;
• defined availability and incident metrics;
• response and resolution commitments for severity-one incidents;
• tested export, backup and exit assistance;
• security, breach-notification and audit provisions;
• a general liability cap with negotiated super-caps for confidentiality, data misuse and intellectual-property claims;
• indemnity procedures and insurance evidence;
• transparent consumer renewal and cancellation journeys.

Technically, Northstar should maintain reconciliation controls, idempotency protections for order submission, staged testing, monitoring and a business-continuity plan. Contract evidence should be stored with the accepted version and acceptance event.

Outcome and learning points

The case demonstrates that contractual risk is jointly produced by law, procurement, product design and system architecture. An SLA without reliable monitoring is difficult to enforce. A liability cap without risk analysis can leave the customer under-protected. A consumer-facing interface can create liability even where backend contracts appear carefully drafted. The strongest compliance programme aligns legal terms, user experience, security controls and operational evidence.

10. Governance, Ethics and Professional Practice

IT compliance professionals should establish a contract-lifecycle control framework. At minimum, it should include:

1. Classification: identify transaction type, value, data sensitivity and regulatory exposure.
2. Approval: define who may negotiate, accept, sign or amend terms.
3. Template control: maintain approved clauses and jurisdictional variants.
4. Evidence preservation: retain terms, logs, consent records and notices.
5. Monitoring: measure SLA, security, renewal and consumer obligations.
6. Change management: assess legal impact before software or policy changes.
7. Incident response: connect technical incidents with contractual notice duties.
8. Exit planning: preserve data portability, continuity and deletion evidence.
9. Review: audit suppliers, platform practices and automated decisions.

Ethically, organisations should avoid manipulative consent interfaces, exploitative default settings, unexplained automated decisions and contractual complexity designed to defeat reasonable understanding. Accessibility is also a compliance concern: users with disabilities or limited digital literacy must have a practical opportunity to review and accept terms.

Artificial intelligence introduces additional contractual questions concerning training data, output ownership, confidentiality, accuracy, human oversight, model changes and allocation of regulatory risk. An AI vendor agreement should not merely promise “responsible AI”; it should specify testing, prohibited uses, incident reporting, audit rights, data segregation and remedies.

Contemporary Developments and Limitations

Cross-border digital commerce increasingly involves overlapping regimes for electronic identification, consumer rights, privacy, cybersecurity, platform accountability, tax and digital assets. Mutual recognition of signatures is uneven. Cloud supply chains make it difficult to identify the responsible entity. Standard terms may be offered on a take-it-or-leave-it basis while still being modified through continuous deployment.

No technical control guarantees legal validity. Strong authentication cannot cure an unlawful purpose; immutable records cannot cure a lack of notice; and a well-drafted clause cannot always exclude mandatory statutory rights. Conversely, legal wording without reliable technical evidence may be impossible to enforce. The appropriate method is integrated legal-technical governance, supported by documented risk assessment and periodic review.

Best-Practice Checklist

Before launching an electronic contracting or digital-commerce process, ask:

• Is the contracting entity clearly identified?
• Is the user given conspicuous and accessible notice of terms?
• Is affirmative consent captured where appropriate?
• Can the organisation reproduce the exact accepted version?
• Are identity, authority and authentication proportionate to risk?
• Are price, renewal, cancellation and refund terms transparent?
• Are software scope, data rights, security and exit obligations defined?
• Are warranties, indemnities and liability caps commercially coherent?
• Are SLA metrics measurable and linked to remedies?
• Is there a response to outages, coding errors and automated mistakes?
• Do the interface, marketing and contract say the same thing?
• Are statutory consumer and regulatory rights preserved?

Chapter Summary

Electronic transactions are legally meaningful when electronic records, signatures and communications perform functions equivalent to paper-based processes. The strength of an electronic contract depends on notice, intention, authority, identity, integrity, accessibility and evidence. Clickwrap is generally stronger than poorly designed browsewrap because it provides affirmative acceptance, but enforceability remains dependent on context and applicable law.

Software and SaaS agreements must allocate rights and responsibilities for licensing, data, security, availability, changes, third-party dependencies and exit. Warranties, indemnities and limitation clauses must be assessed against statutory restrictions, business criticality and realistic loss exposure. SLAs are useful only when their metrics, exclusions and remedies are precisely defined. Smart contracts automate performance but do not eliminate the need for legal terms, governance, correction mechanisms and human accountability.

The professional approach is integrated: contract design, interface design, authentication, logging, security, procurement, consumer protection and operational monitoring must work together. Digital commerce is therefore not only a legal subject; it is a socio-technical governance problem.

Key Terms

Electronic record: Information created, sent, received or stored in electronic form.

Electronic signature: An electronic method used with the intention of signing or approving a record.

Digital signature: A cryptographic electronic signature based on private and public keys.

Functional equivalence: The principle that electronic methods may satisfy functions traditionally performed by paper.

Clickwrap: Terms accepted through an affirmative click or equivalent action.

Browsewrap: Terms asserted to apply through website use without a distinct acceptance action.

Sign-in-wrap: Terms presented through a notice associated with account registration or login.

Offer: A communication capable of acceptance and intended to create contractual commitment.

Acceptance: Assent to the terms of an offer.

Incorporation: The process by which external terms become part of a contract.

SaaS: Software supplied as an online service rather than installed solely on the customer’s systems.

Service-level agreement: A contract or schedule defining measurable service commitments.

Warranty: A contractual promise concerning a fact, quality or performance.

Indemnity: An undertaking to compensate for specified losses or claims.

Limitation of liability: A clause restricting categories or amounts of recoverable loss.

Service credit: A contractual credit or price adjustment for service-level failure.

Smart contract: Code that executes or records transaction logic, often using a distributed ledger.

Oracle: A data source that supplies external information to automated contract code.

Contract lifecycle management: Processes for creating, approving, storing, monitoring and ending contracts.

Dark pattern: An interface design that manipulates or impairs informed user choice.

Review Questions

Short Answer Questions

1. Distinguish an electronic signature from a digital signature.
2. Identify four types of evidence that can support an online acceptance event.
3. Why is clickwrap generally stronger than poorly designed browsewrap?
4. What is the purpose of a service-level agreement?
5. Explain why code alone is not necessarily a complete legal contract.

Long Answer Questions

1. Explain the functional-equivalence approach to electronic records and signatures, including its limitations.
2. Analyse the principal legal and technical issues in a SaaS agreement.
3. Discuss how consumer-protection principles should influence platform terms and checkout design.
4. Evaluate warranties, indemnities and limitation-of-liability clauses as mechanisms of technology risk allocation.
5. Explain the governance requirements for a legally and operationally reliable smart-contract system.

Analytical / Application Questions

1. A company changes its online terms after customers have subscribed and does not request re-consent. Analyse whether the new terms should govern future transactions and recommend a compliant process.
2. A cloud provider reports 99.95% monthly availability, but excludes two major incidents as third-party failures. Identify the contractual and measurement questions that must be resolved before concluding that the SLA was met.
3. Design a control framework for an online marketplace that addresses electronic consent, seller accountability, consumer cancellation, data security, platform moderation and contract evidence.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a digital signature from an electronic signature?

A. A digital signature is always handwritten and scanned.

B. A digital signature uses cryptographic keys, while an electronic signature is the broader category.

C. An electronic signature is valid only when issued by a government.

D. There is no legal or technical distinction between them.

Correct Answer: B. A digital signature uses cryptographic keys, while an electronic signature is the broader category.

Question 2

Which design most strongly supports enforceability of online terms?

A. A hidden footer link stating that website use implies agreement.

B. Terms displayed only after payment is completed.

C. A conspicuous link to terms followed by a required affirmative acceptance action and preserved version records.

D. A verbal promise by an unidentified customer-service agent.

Correct Answer: C. A conspicuous link to terms followed by a required affirmative acceptance action and preserved version records.

Question 3

What does a cryptographic hash primarily help demonstrate?

A. That the signer had legal capacity.

B. That the document’s content has not changed since the hash was created.

C. That the contract contains fair consumer terms.

D. That a company employee had authority to sign.

Correct Answer: B. That the document’s content has not changed since the hash was created.

Question 4

In a SaaS agreement, which issue is most directly concerned with what happens when the customer leaves the service?

A. Data export and exit assistance.

B. Marketing segmentation.

C. Colour contrast in the user interface.

D. The provider’s office lease.

Correct Answer: A. Data export and exit assistance.

Question 5

Using the chapter’s availability formula, what is availability when agreed time is 720 hours and unavailable time is 0.72 hours?

A. 98.0%

B. 99.0%

C. 99.9%

D. 100.72%

Correct Answer: C. 99.9%

Question 6

Which statement about a limitation-of-liability clause is most accurate?

A. It is always enforceable regardless of its wording or applicable law.

B. It may allocate risk but can be restricted by statutory rules and reasonableness requirements.

C. It automatically replaces every warranty.

D. It guarantees that no third party can bring a claim.

Correct Answer: B. It may allocate risk but can be restricted by statutory rules and reasonableness requirements.

Question 7

What is a principal weakness of relying exclusively on immutable smart-contract code?

A. It cannot execute any predefined logic.

B. It automatically eliminates the need for legal governance.

C. It may continue executing despite error, fraud or changed circumstances.

D. It cannot record transaction events.

Correct Answer: C. It may continue executing despite error, fraud or changed circumstances.

Question 8

Which item is most important when determining whether an SLA has been breached?

A. The provider’s preferred advertising slogan.

B. Precisely defined measurement periods, exclusions and monitoring methods.

C. The number of pages in the contract.

D. The colour of the service dashboard.

Correct Answer: B. Precisely defined measurement periods, exclusions and monitoring methods.

Question 9

Which practice is most likely to create a consumer-protection concern?

A. Providing a clear cancellation path before purchase.

B. Displaying recurring charges prominently.

C. Using a confusing interface that conceals automatic renewal.

D. Giving the consumer a downloadable copy of the terms.

Correct Answer: C. Using a confusing interface that conceals automatic renewal.

Question 10

What does an indemnity generally do in a technology contract?

A. Allocates responsibility for specified losses or claims.

B. Defines the cryptographic hash function.

C. Measures network availability.

D. Automatically transfers ownership of all software.

Correct Answer: A. Allocates responsibility for specified losses or claims.