Electronic Communications & E-Sign Consent
ARCBDS ELECTRONIC COMMUNICATIONS & E-SIGN CONSENT
Document No.: 12 of 14
Version: 1.0
Effective Date: [●]
Last Updated: [●]
Document Owner: Legal / Compliance / Operations
Approved By: [●]
IMPORTANT NOTICE
ARCBDS operates primarily through digital channels.
By giving this Electronic Communications & E-Sign Consent, you agree, to the extent permitted by Applicable Law, that ARCBDS may:
provide agreements electronically;
provide disclosures electronically;
provide risk warnings electronically;
communicate with you electronically;
obtain your acceptance electronically;
use clickwrap acceptance;
use OTP verification;
use electronic signatures;
record timestamps and technical evidence of acceptance;
issue transaction and participation confirmations electronically; and
retain electronic records as evidence of your actions and agreements.
Electronic acceptance may create legally binding obligations.
You should therefore read each document carefully before selecting:
“I Agree”
“Accept”
“Confirm”
“Submit”
“Participate”
or another button that clearly indicates contractual acceptance.
This Consent does not require ARCBDS to treat every checkbox, OTP or electronic acceptance as a Qualified Electronic Signature where that particular legal or technical standard has not been used.
Where Applicable Law requires:
notarisation;
a Qualified Electronic Signature;
a qualified trust service;
physical signature;
original document;
witnessed execution; or
another special formality,
ARCBDS shall use the required method.
1. PURPOSE
The purpose of this Consent is to establish the legal and operational framework for:
a. electronic communications;
b. electronic agreements;
c. electronic notices;
d. electronic disclosures;
e. clickwrap acceptance;
f. OTP confirmation;
g. electronic signatures;
h. digital identity;
i. document version acceptance;
j. electronic delivery;
k. electronic records;
l. timestamps;
m. transaction confirmations;
n. participation confirmations;
o. withdrawal of electronic consent;
p. hardware and software requirements;
q. document storage;
r. evidential records;
s. electronic notices of changes; and
t. separation of contractual communications from optional marketing.
2. SCOPE
This Consent applies to electronic interactions relating to:
a. www.arcbds.com;
b. ARCBDS Accounts;
c. ARCBDS member portals;
d. Founding Circle applications;
e. KYC/KYB;
f. ARCBDS Participation Agreements;
g. Risk Disclosure Statements;
h. Protection Reserve Terms;
i. Contributions;
j. ARCBDS allocations;
k. wallet registration;
l. token releases;
m. transaction records;
n. refunds;
o. complaints;
p. Protection Reserve Claims;
q. referral programmes;
r. privacy notices;
s. compliance requests;
t. security communications;
u. regulatory notices; and
v. other ARCBDS services expressly covered by this Consent.
3. PARTIES
This Consent is between:
ARCBDS Legal Entity:
[ARCB Investment LLC / confirmed ARCBDS operating or contracting entity]
Jurisdiction:
Dubai, United Arab Emirates
Commercial Registration / Licence Number:
[●]
Registered Address:
[●]
and:
the individual or legal entity accepting this Consent electronically, referred to as:
“you”;
“your”;
“Participant”; or
“User”,
as applicable.
4. APPLICABLE LEGAL FRAMEWORK
Electronic communications and signatures shall be administered in accordance with Applicable Law.
Depending on the final ARCBDS structure, this may include:
a. UAE Federal Decree-Law No. 46 of 2021 on Electronic Transactions and Trust Services;
b. the Executive Regulations and other applicable rules under that legislation;
c. applicable UAE evidence and contract laws;
d. applicable consumer-protection laws;
e. applicable data-protection laws;
f. applicable VARA requirements where relevant;
g. applicable foreign electronic-signature and electronic-commerce laws where legally applicable; and
h. other mandatory requirements governing the relevant transaction.
5. ELECTRONIC TRANSACTION PRINCIPLE
To the extent permitted by Applicable Law, the fact that:
a. an agreement is electronic;
b. a disclosure is electronic;
c. a signature is electronic;
d. a notice is electronic; or
e. a record is stored electronically
does not by itself prevent that record or transaction from having legal effect.
6. VOLUNTARY ELECTRONIC DEALING
This Consent records your agreement to conduct applicable ARCBDS dealings electronically.
Where Applicable Law provides that a person cannot be forced to use electronic dealing, your acceptance of this Consent confirms your choice to use ARCBDS's electronic channels for covered transactions.
7. YOUR CONSENT
By accepting this document, you consent to:
a. receive covered communications electronically;
b. review agreements electronically;
c. accept agreements electronically;
d. receive disclosures electronically;
e. receive transaction records electronically;
f. receive regulatory notices electronically where permitted;
g. use OTP or other authentication mechanisms;
h. use electronic-signature methods provided by ARCBDS;
i. have your acceptance recorded electronically; and
j. have electronic evidence retained according to Applicable Law.
8. ELECTRONIC CONTRACTS
You acknowledge that a contract may be formed electronically where:
a. the terms are presented to you;
b. you have a reasonable opportunity to review them;
c. the acceptance action is sufficiently clear;
d. you intentionally perform the acceptance action; and
e. applicable legal requirements are satisfied.
9. CLICKWRAP ACCEPTANCE
ARCBDS may use clickwrap acceptance.
A clickwrap process may require you to:
a. review a document;
b. access the document through a visible link;
c. select a checkbox;
d. select an “I Agree” or similar button; and
e. complete additional authentication where required.
Where properly implemented, your affirmative action may constitute evidence of agreement.
10. NO PASSIVE ACCEPTANCE WHERE EXPRESS ACCEPTANCE IS REQUIRED
Where ARCBDS requires express contractual acceptance, ARCBDS should not rely solely on:
a. silence;
b. failure to close a browser;
c. merely visiting a Website;
d. scrolling;
e. inactivity; or
f. an unrelated action
as acceptance.
A clear affirmative action should be used.
11. SEPARATE MATERIAL ACKNOWLEDGEMENTS
ARCBDS may require separate acknowledgements for material matters including:
a. Participation Agreement;
b. Founding Circle Terms & Conditions;
c. Risk Disclosure Statement;
d. Protection Reserve Terms;
e. market and liquidity risk;
f. KYC accuracy;
g. no-guaranteed-return acknowledgement;
h. electronic communications; and
i. other material disclosures.
This structure is intended to ensure that important risk acknowledgements are not hidden within a single general checkbox.
12. ELECTRONIC SIGNATURE
An electronic signature may take forms permitted under Applicable Law.
Depending on the transaction, ARCBDS may use:
a. typed name;
b. click-to-sign;
c. digital signature;
d. OTP-supported acceptance;
e. cryptographic signature;
f. identity-provider signature;
g. trust-service-provider signature;
h. qualified electronic signature; or
i. another legally recognised method.
13. QUALIFIED ELECTRONIC SIGNATURE
Where ARCBDS specifically uses a Qualified Electronic Signature recognised under Applicable Law, ARCBDS may rely on the legal effect applicable to that signature type.
ARCBDS shall not describe ordinary:
a. checkbox acceptance;
b. OTP entry;
c. typed-name acceptance; or
d. basic clickwrap
as a Qualified Electronic Signature unless the applicable legal and technical requirements for a Qualified Electronic Signature have actually been satisfied.
14. ELECTRONIC SIGNATURE DOES NOT REQUIRE ONE TECHNOLOGY
Unless Applicable Law requires a particular form, ARCBDS may select an appropriate electronic acceptance method based on:
a. transaction risk;
b. Participant type;
c. transaction value;
d. regulatory requirements;
e. security;
f. identity assurance; and
g. operational requirements.
15. OTP ACCEPTANCE
ARCBDS may use One-Time Passwords (“OTP”) to support:
a. login;
b. identity confirmation;
c. contractual acceptance;
d. wallet changes;
e. transaction approval;
f. security changes;
g. withdrawals; or
h. other sensitive actions.
16. OTP EVIDENCE
An OTP record may include:
a. Participant ID;
b. destination email or mobile number in masked form;
c. issuance timestamp;
d. verification timestamp;
e. transaction or document reference;
f. success/failure result;
g. device information;
h. IP information; and
i. other security information.
17. OTP SECURITY
You must not:
a. share OTP codes;
b. forward OTP codes;
c. provide OTP codes to unofficial support personnel;
d. knowingly allow another person to approve your transactions using your OTP; or
e. use another person's OTP without authority.
18. OTP FRAUD WARNING
ARCBDS representatives should not ask you to disclose an OTP merely so the representative can independently access your Account.
If a person requests an OTP unexpectedly, you should treat the request as suspicious.
19. EMAIL VERIFICATION
ARCBDS may require email verification before permitting contractual acceptance.
Verification may include:
a. verification link;
b. OTP;
c. authentication code; or
d. another approved method.
20. MOBILE VERIFICATION
Where mobile verification is used, you are responsible for maintaining reasonable control over the mobile number associated with your Account.
You should promptly notify ARCBDS if:
a. your number changes;
b. your SIM is lost;
c. you suspect SIM swapping; or
d. your mobile account is compromised.
21. MULTI-FACTOR AUTHENTICATION
ARCBDS may require multi-factor authentication for higher-risk actions.
MFA may combine:
a. password;
b. OTP;
c. authenticator application;
d. biometric device authentication;
e. hardware security key; or
f. another approved authentication factor.
22. DIGITAL IDENTITY
Where permitted and operationally implemented, ARCBDS may use approved digital-identity services to:
a. verify identity;
b. authenticate users;
c. support electronic signatures; or
d. facilitate electronic transactions.
Use of a particular digital identity system shall be disclosed where applicable.
23. CORPORATE ELECTRONIC ACCEPTANCE
A person accepting electronically on behalf of a legal entity confirms that they:
a. are authorised to act for the entity;
b. have authority to bind the entity;
c. have not exceeded internal authority;
d. have obtained required corporate approvals; and
e. will provide evidence of authority where requested.
24. CORPORATE SIGNING AUTHORITY
ARCBDS may require corporate evidence including:
a. board resolution;
b. power of attorney;
c. authorised-signatory list;
d. corporate mandate;
e. constitutional documents; or
f. other authority evidence.
Electronic acceptance does not cure a lack of legal authority to bind a company.
25. MULTIPLE SIGNATORIES
Where a legal entity requires multiple authorised signatories, ARCBDS may require:
a. separate electronic signatures;
b. sequential approval;
c. dual approval;
d. qualified electronic signatures; or
e. another appropriate method.
26. LEGAL REPRESENTATIVES
A lawyer, trustee, executor, administrator, attorney or other legal representative may be required to provide evidence of authority before electronically acting for another person.
27. RECORD OF ACCEPTANCE
For material agreements, ARCBDS should maintain evidence including:
a. Participant legal name;
b. Participant ID;
c. Account ID;
d. KYC/KYB reference;
e. document title;
f. document version;
g. document effective date;
h. document identifier;
i. acceptance timestamp;
j. acceptance method;
k. relevant checkbox records;
l. OTP confirmation where used;
m. IP address where appropriate;
n. device/browser information where appropriate;
o. session identifier;
p. applicable transaction reference;
q. electronic-signature evidence;
r. audit-log reference; and
s. copy of the accepted document.
28. DOCUMENT HASHING
Where technically appropriate, ARCBDS may create a cryptographic hash or equivalent integrity record for legal documents.
The purpose is to help demonstrate:
a. which document was accepted;
b. whether the document changed; and
c. integrity of the retained version.
29. VERSION-SPECIFIC ACCEPTANCE
Electronic acceptance applies to the specific document version presented to you.
ARCBDS should be able to identify:
a. which version you accepted;
b. when it was accepted; and
c. what the document contained at that time.
30. NO SILENT DOCUMENT REPLACEMENT
ARCBDS should not replace the contents of an already accepted document while retaining the same version identifier in a manner that obscures the change.
Material document changes should receive:
a. a new version;
b. updated effective date; or
c. another auditable change identifier.
31. COPY OF AGREEMENT
After entering into a material Participant Agreement, ARCBDS should provide or make available a copy that the Participant can:
a. view;
b. download;
c. save; and/or
d. print,
subject to reasonable technical standards.
32. DOWNLOADABLE FORMAT
Legal documents should ordinarily be made available in a durable or retrievable electronic format, such as:
a. PDF;
b. HTML with printing capability;
c. secure Account archive; or
d. another format capable of being retained by the Participant.
33. DOCUMENT ARCHIVE
The ARCBDS Account may provide a Legal Documents area containing:
a. current agreements;
b. accepted versions;
c. acceptance dates;
d. transaction confirmations;
e. risk disclosures;
f. privacy documents; and
g. other relevant records.
34. ELECTRONIC COMMUNICATIONS COVERED
Covered electronic communications may include:
a. legal agreements;
b. notices;
c. statements;
d. transaction receipts;
e. Participation Confirmations;
f. KYC notices;
g. compliance requests;
h. risk disclosures;
i. wallet notices;
j. release notices;
k. refund decisions;
l. Protection Reserve Claim decisions;
m. security alerts;
n. Account updates;
o. service announcements;
p. regulatory notices;
q. policy amendments;
r. complaints correspondence; and
s. other service-related information.
35. ELECTRONIC DELIVERY METHODS
ARCBDS may provide covered communications through:
a. registered email;
b. Account inbox;
c. dashboard notification;
d. secure document centre;
e. SMS;
f. in-app or Website notification;
g. electronic-signature platform; or
h. another electronic method agreed or legally permitted.
36. PRIMARY EMAIL ADDRESS
Your registered email address will ordinarily be treated as an official electronic communication address.
You are responsible for keeping it current.
37. MOBILE NUMBER
Your registered mobile number may be used for:
a. OTP;
b. security alerts;
c. Account recovery;
d. transaction verification; and
e. other permitted communications.
38. ACCOUNT INBOX
Where ARCBDS provides a secure Account inbox, legally relevant communications may be delivered there.
Users should review the Account inbox periodically.
39. SERVICE COMMUNICATIONS
You acknowledge that ARCBDS may send communications necessary for the contractual relationship even if you opt out of marketing.
These may include:
a. Account security;
b. transaction notices;
c. KYC requests;
d. legal-document updates;
e. risk notices;
f. payment notices;
g. regulatory communications;
h. complaints responses; and
i. other necessary service communications.
40. MARKETING COMMUNICATIONS ARE SEPARATE
Consent to electronic contractual communications does not automatically constitute consent to receive optional marketing.
Optional marketing consent should be collected separately where required.
41. MARKETING OPT-OUT
You may unsubscribe from optional marketing without withdrawing this Consent for essential contractual communications.
42. NO SERVICE CONDITION ON OPTIONAL MARKETING
Where marketing consent is optional under Applicable Law, ARCBDS should not make acceptance of optional promotional communications a condition of Founding Circle participation.
43. ELECTRONIC DELIVERY TIMING
Subject to Applicable Law, an electronic communication may be considered delivered when it is:
a. sent to the registered electronic address;
b. placed in the designated secure Account area;
c. otherwise made available through the agreed electronic method; or
d. delivered according to another legally recognised rule.
Mandatory legal rules concerning dispatch or receipt shall prevail.
44. FAILED EMAIL DELIVERY
If ARCBDS receives evidence that an important email was not delivered, ARCBDS may:
a. attempt another channel;
b. place a notice in the Account;
c. request updated contact details;
d. restrict certain activity until contact details are corrected; or
e. use another lawful method.
45. SPAM FILTERS
You are responsible for taking reasonable steps to ensure ARCBDS communications are not unnecessarily blocked by:
a. spam filters;
b. email rules;
c. full mailboxes; or
d. outdated contact information.
46. CHANGE OF EMAIL ADDRESS
You should promptly update your registered email if it changes.
A change may require:
a. password confirmation;
b. OTP;
c. MFA;
d. identity verification;
e. cooling period; or
f. security review.
47. CHANGE OF MOBILE NUMBER
A mobile-number change may require enhanced verification to reduce Account takeover risk.
48. CONTACT DETAILS ARE PARTICIPANT RESPONSIBILITY
Failure to maintain accurate contact information may result in:
a. missed notices;
b. delayed transactions;
c. security risks;
d. inability to receive OTP; or
e. temporary Account restrictions.
49. ELECTRONIC PARTICIPATION CONFIRMATION
The Participant Confirmation may be issued electronically.
It may state:
a. Participation Category;
b. Contribution;
c. Allocation Price;
d. base ARCBDS;
e. Alignment Reward;
f. total entitlement;
g. Cliff;
h. release terms;
i. transaction hash;
j. agreement version; and
k. acceptance timestamp.
50. ELECTRONIC TRANSACTION RECEIPTS
ARCBDS may issue electronic receipts for:
a. Contributions;
b. refunds;
c. distributions;
d. wallet transfers;
e. Protection Reserve settlements; and
f. other transactions.
51. BLOCKCHAIN RECORDS
Blockchain transaction records may supplement ARCBDS electronic records.
A blockchain record may demonstrate that an on-chain transaction occurred.
It does not by itself necessarily establish:
a. legal identity;
b. legal ownership;
c. contractual purpose; or
d. contractual entitlement.
52. ELECTRONIC RECORDS AS EVIDENCE
To the extent permitted by Applicable Law, ARCBDS may rely on electronic records as evidence of:
a. Account activity;
b. contractual acceptance;
c. document delivery;
d. transaction authorisation;
e. wallet changes;
f. risk acknowledgement;
g. OTP verification; and
h. communications.
53. AUDIT LOGS
ARCBDS may maintain audit logs showing:
a. login;
b. logout;
c. document access;
d. checkbox acceptance;
e. form submission;
f. OTP verification;
g. transaction approval;
h. wallet update;
i. password change;
j. Account restriction;
k. agreement acceptance; and
l. other material Account events.
54. Timestamps
ARCBDS shall maintain a consistent timestamp framework for legally significant records.
Relevant logs should identify:
a. date;
b. time;
c. timezone; and
d. event.
55. OFFICIAL RECORD TIMEZONE
Unless otherwise stated:
Electronic Contract Record Timezone: [UTC / UTC+8 / ●]
The production system should use an unambiguous standard.
56. QUALIFIED TIMESTAMPS
Where a Qualified Electronic Time Stamp is legally or operationally required, ARCBDS shall use an appropriate qualified trust service.
Ordinary server timestamps shall not be described as qualified timestamps unless the relevant standard is satisfied.
57. DATA INTEGRITY
Electronic legal records should be protected against unauthorised:
a. alteration;
b. deletion;
c. replacement;
d. backdating; and
e. tampering.
58. RECORD SECURITY
Security measures may include:
a. access controls;
b. encryption;
c. hashing;
d. role-based permissions;
e. immutable logs;
f. backups;
g. monitoring;
h. audit trails; and
i. change control.
59. RECORD RETENTION
ARCBDS shall retain electronic contractual and transaction records for the period required by:
a. contractual law;
b. AML/CFT law;
c. VARA rules where applicable;
d. consumer law;
e. tax law;
f. litigation requirements;
g. data-protection law; and
h. other Applicable Law.
60. EIGHT-YEAR RECORD REQUIREMENTS
Where an applicable VARA or AML recordkeeping requirement requires records to be retained for at least eight years, ARCBDS shall apply that period to relevant records.
Longer retention may apply where legally required.
61. ACCESS TO STORED DOCUMENTS
Participants may request copies of relevant agreements or records, subject to:
a. identity verification;
b. retention availability;
c. security;
d. privacy rights of others;
e. legal privilege; and
f. Applicable Law.
62. ELECTRONIC COMMUNICATION SECURITY
Electronic communication carries risks including:
a. phishing;
b. spoofing;
c. interception;
d. malware;
e. compromised email accounts;
f. SIM swapping;
g. unauthorised Account access; and
h. fraudulent websites.
You should verify communications carefully.
63. OFFICIAL DOMAIN
Users should verify that communications and legal-document links use official ARCBDS channels.
Official Website:
www.arcbds.com
Official email domains and communication channels should be published through the Website.
64. PHISHING
ARCBDS may send links to official legal documents or Account functions.
You should avoid clicking suspicious links received from:
a. unknown Telegram accounts;
b. private social-media messages;
c. unofficial domains;
d. fake support personnel; or
e. unknown shortened URLs.
65. PRIVATE KEYS AND SEED PHRASES
No legitimate ARCBDS electronic agreement or signature process should require you to disclose:
a. private key;
b. seed phrase;
c. recovery phrase; or
d. equivalent wallet-control secret.
66. WALLET SIGNATURES
Where a cryptographic wallet signature is used to prove control of a wallet, ARCBDS should clearly state:
a. what is being signed;
b. whether the signature authorises a blockchain transaction;
c. whether it merely proves wallet control; and
d. the relevant legal purpose.
67. BLIND SIGNING
Participants should avoid approving unclear or unreadable wallet-signing requests.
Where ARCBDS uses wallet signatures, message content should be understandable where technically possible.
68. HARDWARE REQUIREMENTS
To use electronic services, you generally require:
a. internet access;
b. compatible browser;
c. suitable device;
d. valid email address;
e. mobile number where OTP is used;
f. software capable of displaying legal documents; and
g. storage or printing capability if you wish to retain personal copies.
69. SUPPORTED BROWSERS
ARCBDS may publish a list of supported browsers.
Older browsers may not support:
a. security features;
b. electronic signatures;
c. document display; or
d. Account functionality.
70. PDF ACCESS
Where documents are provided in PDF format, you need software capable of displaying PDF files.
ARCBDS should not require proprietary software where a reasonable widely available alternative exists.
71. ACCESSIBILITY
ARCBDS should seek to make legally significant electronic documents reasonably accessible.
Users who experience accessibility barriers may contact:
Accessibility / Support: [●]
Reasonable alternative arrangements may be considered where required by Applicable Law.
72. LANGUAGE
Legal documents may be presented in English and translated versions.
Where the English version is designated as controlling, that designation applies only to the extent permitted by Applicable Law.
73. TRANSLATIONS
A translated electronic document should clearly identify whether it is:
a. controlling; or
b. provided for convenience.
ARCBDS should avoid materially inconsistent translations.
74. OPPORTUNITY TO REVIEW
Before material acceptance, ARCBDS should provide a reasonable opportunity to:
a. open the document;
b. read the document;
c. download or print it;
d. ask questions where appropriate; and
e. decline acceptance.
75. NO FORCED SCROLL AS SOLE PROOF OF READING
ARCBDS may require scrolling as a user-interface control, but scrolling alone does not prove that a Participant understood a document.
Material acknowledgements may therefore require affirmative checkbox acceptance.
76. RISK DISCLOSURE ACCEPTANCE
The ARCBDS Risk Disclosure Statement should receive clear affirmative acknowledgement.
The record should identify:
a. Risk Disclosure version;
b. acceptance time;
c. Participant ID; and
d. acceptance method.
77. PROTECTION RESERVE ACCEPTANCE
The Participant Protection Reserve Terms should be separately accessible before participation where the Reserve forms part of the Participant's commercial understanding.
ARCBDS should not represent the Reserve solely through abbreviated marketing copy.
78. KYC DECLARATIONS
KYC declarations may be electronically accepted.
The Participant remains responsible for accuracy even where the form is completed digitally.
79. PARTICIPANT DECLARATION
Electronic acceptance may include confirmation that:
a. information is accurate;
b. funds are lawful;
c. the Participant acts for themselves or disclosed principal;
d. risk has been reviewed;
e. terms are accepted; and
f. electronic dealing is accepted.
80. NO PRE-TICKED CONTRACT ACCEPTANCE
Material contractual checkboxes should not be pre-ticked.
Acceptance should reflect an affirmative Participant action.
81. OPTIONAL MARKETING CHECKBOX
Optional marketing consent should:
a. be separately labelled;
b. not be pre-ticked where affirmative consent is required;
c. not be bundled into required contract acceptance; and
d. be withdrawable.
82. ELECTRONIC AMENDMENTS
ARCBDS may provide amended documents electronically.
Where an amendment requires acceptance, ARCBDS may require a new:
a. checkbox;
b. OTP;
c. electronic signature; or
d. other acceptance event.
83. NOTICE OF AGREEMENT CHANGES
Where VARA's Client Agreement rules apply to the relevant relationship, changes to Client Agreements shall be notified at least 30 calendar days before taking effect, subject to applicable exceptions and mandatory legal requirements.
Other agreements shall follow their own contractual and legal notice requirements.
84. EMERGENCY LEGAL CHANGES
A change required immediately by:
a. law;
b. court order;
c. sanctions;
d. regulator; or
e. material security requirement
may need to take effect sooner than an ordinary notice period where Applicable Law permits or requires.
85. RECORD OF CHANGES
ARCBDS should maintain:
a. previous document version;
b. new document version;
c. change summary;
d. effective date;
e. notification date; and
f. acceptance status where required.
86. WITHDRAWAL OF ELECTRONIC CONSENT
You may request withdrawal of this Consent for future electronic dealings to the extent permitted by Applicable Law.
Withdrawal does not automatically invalidate:
a. previous electronic signatures;
b. previous agreements;
c. previous transactions;
d. previous communications; or
e. records created before withdrawal.
87. HOW TO WITHDRAW CONSENT
A withdrawal request may be submitted through:
Electronic Consent Contact: [●]
or another official ARCBDS channel.
ARCBDS may verify your identity before processing the request.
88. EFFECT OF WITHDRAWAL
Because ARCBDS is designed as a digital service, withdrawal of electronic-consent capability may mean that ARCBDS can no longer provide some or all services to you.
Possible consequences include:
a. inability to enter new digital agreements;
b. inability to submit new participations;
c. restriction of Account functionality;
d. requirement for an alternative signing method; or
e. Account closure for future services where legally permitted.
89. EXISTING RIGHTS AFTER WITHDRAWAL
Withdrawal of electronic consent does not automatically eliminate lawfully accrued:
a. ARCBDS entitlement;
b. transaction records;
c. obligations;
d. claims;
e. release schedules; or
f. other existing contractual rights.
90. PAPER DOCUMENTS
ARCBDS does not guarantee that every document will be available through a paper-based process.
Where Applicable Law requires a paper copy or another non-electronic alternative, ARCBDS shall comply.
Where optional paper copies are available, reasonable delivery costs may apply if lawfully disclosed.
91. REQUESTING A PAPER COPY
Where available, a Participant may request a paper copy through:
Legal Documents Contact: [●]
ARCBDS may verify identity before releasing confidential documents.
92. WET-INK SIGNATURE
ARCBDS may require a wet-ink signature where:
a. Applicable Law requires it;
b. a regulator requires it;
c. notarisation is necessary;
d. corporate formalities require it;
e. electronic verification is inadequate; or
f. risk justifies a stronger method.
93. NOTARISATION
This Consent does not replace notarisation where notarisation is legally required.
94. WITNESSING
This Consent does not remove a witness requirement where Applicable Law requires witnessing.
95. QUALIFIED TRUST SERVICES
ARCBDS may use a licensed or recognised trust-service provider where:
a. qualified electronic signatures are required;
b. electronic seals are required;
c. qualified timestamps are required;
d. electronic delivery certification is required; or
e. enhanced evidential assurance is appropriate.
96. ELECTRONIC SEALS
Where legally appropriate, ARCBDS may use an electronic seal to authenticate Company-issued electronic documents.
An electronic seal is distinct from an individual's electronic signature.
97. DOCUMENT AUTHENTICITY
ARCBDS may provide methods for verifying document authenticity, such as:
a. verification code;
b. QR code;
c. document ID;
d. digital certificate;
e. electronic seal;
f. cryptographic hash; or
g. secure Account verification.
98. E-SIGNATURE SERVICE PROVIDERS
ARCBDS may appoint third-party electronic-signature or trust-service providers.
Provider: [●]
Before appointment, ARCBDS should assess:
a. legal recognition;
b. security;
c. identity assurance;
d. privacy;
e. audit logs;
f. data retention;
g. international transfers;
h. business continuity; and
i. applicable licensing.
99. THIRD-PARTY SIGNING TERMS
Where a third-party signing provider is used, that provider may have separate:
a. terms;
b. privacy notices;
c. security procedures; and
d. authentication requirements.
Use of a third-party provider does not remove ARCBDS's obligations under applicable agreements.
100. DATA PROTECTION
Electronic acceptance may involve Personal Data including:
a. IP address;
b. device information;
c. timestamp;
d. email;
e. mobile number;
f. signature data;
g. authentication logs; and
h. document interaction records.
Such information shall be processed under the ARCBDS Privacy Policy.
101. BIOMETRIC SIGNATURE OR AUTHENTICATION
Where biometric information is used, ARCBDS shall provide applicable notices and obtain any required consent.
Biometric authentication used locally on a user's device may be technically different from ARCBDS collecting biometric data directly.
102. ELECTRONIC IDENTITY FRAUD
ARCBDS may suspend electronic execution where it suspects:
a. Account takeover;
b. identity theft;
c. forged documents;
d. stolen OTP;
e. SIM swap;
f. unauthorised signatory;
g. automated fraud; or
h. other compromise.
103. DISPUTED ELECTRONIC SIGNATURE
If you claim that an electronic acceptance was unauthorised, ARCBDS may investigate:
a. Account logs;
b. authentication records;
c. OTP records;
d. IP history;
e. device information;
f. KYC;
g. email records;
h. transaction records;
i. signing-provider records; and
j. other relevant evidence.
104. NO AUTOMATIC PRESUMPTION FROM ACCOUNT ACCESS
ARCBDS should evaluate the complete evidence where electronic acceptance is disputed.
The fact that an action originated from an Account may be material evidence but does not prevent investigation of credible Account-compromise allegations.
105. PARTICIPANT SECURITY DUTIES
You should:
a. protect your password;
b. protect OTP access;
c. enable MFA;
d. secure your email;
e. secure your mobile device;
f. review agreements before acceptance;
g. report suspected Account compromise promptly; and
h. avoid allowing unauthorised persons to use your Account.
106. SHARED DEVICES
Use of shared devices increases risk.
Participants should:
a. log out after use;
b. avoid saving passwords;
c. avoid leaving agreements open;
d. protect OTP access; and
e. use secure devices for high-value transactions.
107. BUSINESS ACCOUNT ACCESS
A corporate Participant should ensure only authorised personnel can:
a. access the Account;
b. approve contracts;
c. change wallets;
d. authorise Contributions; and
e. submit Claims.
108. INTERNAL AUTHORITY DOES NOT BIND ARCBDS AUTOMATICALLY
A corporate Participant is responsible for configuring its internal approval process.
ARCBDS may rely on authorised representatives identified in its records to the extent permitted by law and applicable agreements.
109. ELECTRONIC COMPLAINTS
Participants may submit complaints electronically.
An electronic complaint should be recorded with:
a. complaint ID;
b. date;
c. Participant ID;
d. issue; and
e. response history.
110. ELECTRONIC CLAIMS
Protection Reserve Claims may be electronically submitted.
The Claimant may be required to electronically declare that:
a. information is accurate;
b. evidence is genuine;
c. the Claim is not duplicated; and
d. token ownership is lawful.
111. ELECTRONIC REFUND REQUESTS
Cancellation and Refund Requests may be submitted electronically.
ARCBDS may require additional authentication before directing assets to a wallet.
112. ELECTRONIC WALLET CHANGES
Wallet changes are security-sensitive and may require stronger electronic verification than ordinary Website activity.
113. HIGH-RISK TRANSACTIONS
ARCBDS may require enhanced signing or authentication for:
a. high-value withdrawals;
b. large institutional transactions;
c. wallet changes;
d. post-compromise recovery;
e. unusual transactions;
f. material corporate amendments; or
g. other high-risk events.
114. SIGNATURE LEVEL BY RISK
ARCBDS may apply a tiered model:
Standard
Clickwrap + authenticated Account.
Enhanced
Clickwrap + OTP/MFA.
High Assurance
Enhanced digital signature or identity verification.
Qualified
Qualified Electronic Signature or equivalent legally required process.
The actual level shall depend on the transaction and Applicable Law.
115. AUTOMATED RECORD CREATION
ARCBDS systems may automatically create electronic records following:
a. acceptance;
b. Contribution;
c. blockchain confirmation;
d. allocation;
e. release;
f. withdrawal;
g. refund; or
h. Claim settlement.
Automated creation does not remove the requirement for accuracy.
116. MANIFEST SYSTEM ERROR
A system error may be corrected according to applicable ARCBDS policies.
An incorrect electronic display does not automatically create a contractual entitlement inconsistent with the valid agreement and verified transaction records.
117. ELECTRONIC NOTICES FROM PARTICIPANTS
Where an agreement requires notice from the Participant, notice must be sent through an authorised channel identified in that agreement or on the Website.
A message to an unauthorised community account may not constitute contractual notice.
118. OFFICIAL NOTICE CHANNELS
Official ARCBDS notice channels may include:
Legal Email: [●]
Compliance Email: [●]
Support Portal: [●]
Registered Address: [●]
Account Message Centre: [●]
119. ELECTRONIC SERVICE OF FORMAL LEGAL PROCESS
This Consent does not automatically mean that every form of court process or formal legal service may be served by ordinary email.
Formal legal service shall follow:
a. governing law;
b. court rules;
c. arbitration rules; and
d. express contractual provisions.
120. LEGALLY MANDATED DELIVERY METHODS
Where Applicable Law requires a specific delivery method, ARCBDS shall use that method rather than relying solely on this Consent.
121. REGULATORY COMMUNICATIONS
ARCBDS may be required to send regulatory notices electronically.
Such notices may concern:
a. changes to services;
b. risk disclosures;
c. regulatory status;
d. material incidents;
e. Account restrictions; or
f. other required matters.
122. COMMUNICATIONS FROM REGULATORS
ARCBDS may display links or information from competent regulators.
A regulator's communication may be subject to its own legal and publication requirements.
123. ELECTRONIC EVIDENCE RETENTION AFTER ACCOUNT CLOSURE
Account closure does not require ARCBDS to delete electronic contractual records that must be retained for:
a. AML/CFT;
b. tax;
c. legal claims;
d. regulatory obligations;
e. fraud prevention; or
f. other lawful reasons.
124. DEATH OR INCAPACITY
Electronic access by a deceased or incapacitated Participant's representative may require:
a. probate documents;
b. court authority;
c. power of attorney where valid;
d. identity verification; and
e. other legal documentation.
Possession of the Participant's password alone does not establish lawful authority.
125. BUSINESS CONTINUITY
ARCBDS should maintain arrangements designed to preserve access to material electronic records during:
a. system outage;
b. cyberattack;
c. cloud failure;
d. disaster;
e. vendor failure; or
f. business restructuring.
126. BACKUPS
Material contractual records should be backed up according to applicable information-security and retention requirements.
127. MIGRATION OF SYSTEMS
If ARCBDS changes its electronic-signature, document-management or Account platform, records should be migrated in a manner intended to preserve:
a. content;
b. version;
c. acceptance evidence;
d. timestamps;
e. integrity; and
f. audit trails.
128. SERVICE PROVIDER FAILURE
If a signing provider becomes unavailable, ARCBDS may implement another legally compliant signing method.
Previous valid agreements remain effective subject to Applicable Law.
129. FORCE MAJEURE
Electronic communications may be delayed by:
a. internet outage;
b. telecommunications failure;
c. cyberattack;
d. natural disaster;
e. war;
f. government action;
g. power failure; or
h. other events beyond reasonable control.
Mandatory legal rights remain unaffected.
130. CHANGES TO THIS CONSENT
ARCBDS may update this Consent because of:
a. legal changes;
b. regulatory changes;
c. technology;
d. security;
e. signing-provider changes;
f. communication-channel changes; or
g. operational improvements.
131. MATERIAL CHANGES
Where a material change requires renewed acceptance, ARCBDS shall obtain appropriate electronic acceptance before relying on the new term.
132. EXISTING ELECTRONIC AGREEMENTS
Updating this Consent does not retroactively invalidate electronic agreements that were validly entered under an earlier version.
133. VERSION CONTROL
ARCBDS shall maintain:
a. version number;
b. effective date;
c. prior versions;
d. change summary;
e. acceptance records; and
f. implementation records.
134. SEVERABILITY
If part of this Consent is invalid or unenforceable, the remainder shall continue to the maximum extent permitted by Applicable Law.
135. NO WAIVER
Failure to enforce a provision immediately does not constitute permanent waiver.
136. GOVERNING LAW
This Consent shall be governed by the same governing law as the ARCBDS Founding Circle Participation Agreement.
Final Governing Law: [●]
137. DISPUTE RESOLUTION
Disputes concerning electronic acceptance or communications shall follow the dispute-resolution mechanism in the applicable ARCBDS agreement, subject to mandatory legal rights.
138. LANGUAGE
The controlling language shall be English to the extent legally permitted.
Translations may be provided for convenience.
139. CONTACT
ARCBDS ELECTRONIC DOCUMENTS & COMMUNICATIONS
Official Website:
www.arcbds.com
Legal Entity:
[●]
Legal:
[●]
Electronic Consent:
[●]
Participant Support:
[●]
Compliance:
[●]
Registered Address:
[●]
SCHEDULE 1
ELECTRONIC DOCUMENTS COVERED
Your electronic consent may apply to:
☐ Founding Circle Participation Agreement
☐ Founding Circle Terms & Conditions
☐ Risk Disclosure Statement
☐ Participant Protection Reserve Terms
☐ Website Terms of Use
☐ Privacy Policy acknowledgements where applicable
☐ Cookie settings/consent where applicable
☐ KYC/AML declarations
☐ Payment & Blockchain Transaction Policy
☐ Cancellation & Refund Policy
☐ Eligibility & Restricted Jurisdiction Policy
☐ Electronic Communications & E-Sign Consent
☐ Legal & Marketing Disclaimer
☐ Referral & Rewards Terms
☐ Participation Confirmations
☐ Transaction Receipts
☐ Refund Records
☐ Protection Reserve Claims
☐ Wallet-Change Requests
☐ Complaints
☐ Account Notices
☐ Amendments
☐ Other service documents expressly presented electronically
SCHEDULE 2
FOUNDING CIRCLE ACCEPTANCE FLOW
Step 1 — Participant Authenticated
Account login + required security.
↓
Step 2 — Participant Details Confirmed
KYC/KYB identity matched.
↓
Step 3 — Participation Category Selected
Access / Growth / Legacy.
↓
Step 4 — Legal Documents Presented
Links to current versions.
↓
Step 5 — Separate Risk Acknowledgement
Risk Disclosure affirmatively accepted.
↓
Step 6 — Protection Reserve Acknowledgement
Conditional nature clearly accepted.
↓
Step 7 — Participation Agreement Acceptance
Checkbox / e-sign.
↓
Step 8 — Electronic Communications Consent
Accepted.
↓
Step 9 — OTP / MFA
Where required.
↓
Step 10 — Audit Record Created
Version + timestamp + Participant + device/security data.
↓
Step 11 — Contribution
Payment instructions provided.
↓
Step 12 — Final Participation Confirmation
Electronic copy made available.
SCHEDULE 3
RECOMMENDED ACCEPTANCE CHECKBOXES
Before participation:
☐ I have read and agree to the ARCBDS Founding Circle Participation Agreement.
☐ I have read and agree to the ARCBDS Founding Circle Terms & Conditions.
☐ I have read and understood the ARCBDS Risk Disclosure Statement.
☐ I understand that ARCBDS can lose value and that liquidity and exchange listing are not guaranteed.
☐ I have read and agree to the ARCBDS Participant Protection Reserve Terms.
☐ I understand that the Participant Protection Reserve is conditional, finite, and does not guarantee my Contribution or ARCBDS market value.
☐ I confirm that the information I have provided for KYC/KYB and participation is accurate.
☐ I agree to conduct applicable ARCBDS transactions electronically and consent to receive covered communications electronically.
☐ I agree that my affirmative electronic acceptance may create legally binding obligations.
OPTIONAL MARKETING
The following should remain separate:
☐ I would like to receive optional ARCBDS news, events, ecosystem updates and marketing communications.
Optional marketing consent is not required for participation where the law does not require otherwise.
SCHEDULE 4
ELECTRONIC ACCEPTANCE AUDIT RECORD
For each material acceptance:
Participant Legal Name: [●]
Participant ID: [●]
Account ID: [●]
KYC/KYB ID: [●]
Document Title: [●]
Document Version: [●]
Document Effective Date: [●]
Document Hash / Integrity Reference: [●]
Acceptance Method:
☐ Clickwrap
☐ OTP
☐ E-Signature
☐ Qualified E-Signature
☐ Wallet Signature
☐ Other
Acceptance Timestamp: [●]
Timezone: [●]
IP Address: [●]
Device / Browser Record: [●]
Session ID: [●]
OTP Reference: [●]
Transaction Reference: [●]
Copy Delivered: Yes / No
Delivery Method: [●]
SCHEDULE 5
ELECTRONIC PARTICIPATION CONFIRMATION
Confirmation Number: [●]
Participant: [●]
Participant ID: [●]
Category: Access / Growth / Legacy
Accepted Contribution: [●]
Allocation Price: [●]
Base ARCBDS: [●]
Alignment Reward: [●]
Total ARCBDS Entitlement: [●]
Cliff: [●]
Release Schedule: [●]
Transaction Hash: [●]
Participation Agreement Version: [●]
Risk Disclosure Version: [●]
Protection Reserve Terms Version: [●]
Electronic Acceptance Record: [●]
Acceptance Date / Time: [●]
SCHEDULE 6
ELECTRONIC COMMUNICATION CHANNELS
Communication
Primary Method
Secondary Method
Contract Documents
Account / Email
Downloadable PDF
Risk Disclosures
Account / Website
Transaction Receipts
Account
Participation Confirmation
Account
Security Alert
Email / SMS
Account
KYC Request
Account / Email
[●]
Legal Notice
Email / Account
[●]
Policy Update
Email / Account
Website
Complaint Response
Email / Account
[●]
Protection Reserve Claim
Account / Email
[●]
Optional Marketing
Consent-based channel
[●]
SCHEDULE 7
TECHNICAL REQUIREMENTS
To participate electronically, a User should have:
☐ Internet connection
☐ Supported browser
☐ Valid email address
☐ Mobile number where required
☐ Device capable of displaying HTML/PDF
☐ Ability to download or retain documents
☐ Authentication capability
☐ MFA/OTP capability where required
ARCBDS should clearly notify Participants if technical requirements materially change.
SCHEDULE 8
WITHDRAWAL OF ELECTRONIC CONSENT FORM
Participant: [●]
Participant ID: [●]
Registered Email: [●]
Request
☐ I request to withdraw my consent to future electronic communications and electronic contracting to the extent permitted by law.
I Understand
☐ Withdrawal does not invalidate previous electronic agreements.
☐ Withdrawal does not cancel existing ARCBDS participation.
☐ ARCBDS may need to restrict future digital services.
☐ ARCBDS may continue sending communications required by law.
☐ ARCBDS may retain existing records where legally required.
Requested Alternative Communication Method: [●]
Signature / Verified Request: [●]
Date: [●]
ARCBDS DECISION
[●]
SCHEDULE 9
DISPUTED ELECTRONIC ACCEPTANCE FORM
Participant: [●]
Participant ID: [●]
Document / Transaction: [●]
Acceptance Date: [●]
Dispute
☐ I did not perform the acceptance.
☐ My Account was compromised.
☐ My OTP was compromised.
☐ The wrong document was displayed.
☐ I could not access the document.
☐ The document version is disputed.
☐ Corporate signatory lacked authority.
☐ Other: [●]
Explanation
[●]
Evidence
[●]
Investigation
☐ KYC reviewed
☐ Login logs reviewed
☐ IP reviewed
☐ Device reviewed
☐ OTP reviewed
☐ Email reviewed
☐ Session reviewed
☐ Document version verified
☐ Document hash verified
☐ Signature-provider data reviewed
☐ Transaction activity reviewed
Outcome
[●]
SCHEDULE 10
DOCUMENT VERSION REGISTER
ARCBDS should maintain:
Document
Version
Effective Date
Replaced Version
Material Change
Acceptance Required?
Participation Agreement
[●]
[●]
[●]
[●]
Yes
Founding Circle T&C
[●]
[●]
[●]
[●]
[●]
Risk Disclosure
[●]
[●]
[●]
[●]
Yes
Protection Reserve Terms
[●]
[●]
[●]
[●]
Yes
Website Terms
[●]
[●]
[●]
[●]
[●]
Privacy Policy
[●]
[●]
[●]
[●]
Where required
Cookie Policy
[●]
[●]
[●]
[●]
Where required
AML Policy
[●]
[●]
[●]
[●]
[●]
Payment Policy
[●]
[●]
[●]
[●]
[●]
Refund Policy
[●]
[●]
[●]
[●]
[●]
Eligibility Policy
[●]
[●]
[●]
[●]
[●]
E-Sign Consent
[●]
[●]
[●]
[●]
Yes
Legal Disclaimer
[●]
[●]
[●]
[●]
[●]
Referral Terms
[●]
[●]
[●]
[●]
Yes where applicable
SCHEDULE 11
ELECTRONIC SIGNATURE ASSURANCE LEVELS
LEVEL 1 — BASIC ELECTRONIC ACCEPTANCE
Suitable where legally appropriate for lower-risk actions.
Possible controls:
authenticated Account;
clickwrap;
timestamp;
IP/session logging.
LEVEL 2 — ENHANCED ELECTRONIC ACCEPTANCE
Suitable for material contractual actions.
Possible controls:
authenticated Account;
clickwrap;
OTP or MFA;
document versioning;
audit trail.
LEVEL 3 — HIGH-ASSURANCE ELECTRONIC SIGNATURE
Suitable for higher-risk corporate or financial actions.
Possible controls:
enhanced identity verification;
digital certificate;
dedicated signing provider;
cryptographic signature;
stronger audit evidence.
LEVEL 4 — QUALIFIED ELECTRONIC SIGNATURE
Used where legally required or deliberately selected.
Must satisfy the applicable legal and trust-service requirements for a Qualified Electronic Signature.
Do not label Levels 1–3 as “Qualified” unless they actually meet Level 4 legal requirements.
SCHEDULE 12
RECORD RETENTION REGISTER
Electronic legal records should include:
☐ Accepted agreement copy
☐ Version
☐ Document hash where used
☐ Acceptance timestamp
☐ Participant ID
☐ KYC reference
☐ IP/session information where retained
☐ OTP evidence
☐ E-signature certificate where applicable
☐ Delivery record
☐ Participation Confirmation
☐ Transaction Hash
☐ Amendment notices
☐ Withdrawal of consent
☐ Disputes
☐ Investigation records
☐ Complaint records
Retention shall follow Applicable Law and the ARCBDS Data Retention Policy.
SCHEDULE 13
LEGAL DOCUMENT DELIVERY NOTICE
After acceptance, the Participant should receive substantially:
YOUR ARCBDS DOCUMENTS
Your ARCBDS participation documents have been accepted electronically.
Please retain copies for your records.
Participant: [●]
Participation Confirmation: [●]
Accepted Date: [●]
Documents
Founding Circle Participation Agreement — Version [●]
Founding Circle Terms & Conditions — Version [●]
Risk Disclosure Statement — Version [●]
Participant Protection Reserve Terms — Version [●]
Payment, Allocation & Blockchain Transaction Policy — Version [●]
Cancellation & Refund Policy — Version [●]
Eligibility & Restricted Jurisdiction Policy — Version [●]
Electronic Communications & E-Sign Consent — Version [●]
Download Documents
[Secure Link / Account Documents]
If you believe you did not authorise this participation, contact ARCBDS immediately through the official support channel.
SCHEDULE 14
SECURITY WARNING
PROTECT YOUR ELECTRONIC SIGNATURE AND ACCOUNT
Never share:
password;
OTP;
MFA code;
private key;
seed phrase; or
recovery phrase.
ARCBDS personnel should never ask you for your wallet seed phrase or private key.
If you receive an unexpected request to electronically approve a transaction or agreement:
DO NOT APPROVE IT.
Access www.arcbds.com independently and verify the request through official support.
SCHEDULE 15
INTERNAL IMPLEMENTATION CHECKLIST
Before launching electronic Founding Circle execution:
☐ Final contracting entity confirmed
☐ Final governing law confirmed
☐ Electronic-signature legal review completed
☐ Applicable UAE formalities reviewed
☐ VARA requirements reviewed where applicable
☐ Corporate-signature requirements reviewed
☐ Participation Agreement uploaded
☐ Risk Disclosure uploaded
☐ Protection Reserve Terms uploaded
☐ Version numbers activated
☐ Document hashes configured where used
☐ Clickwrap checkboxes configured
☐ Optional marketing separated
☐ OTP/MFA configured
☐ Audit logs configured
☐ Timestamp timezone confirmed
☐ Downloadable copies available
☐ Post-signing copies delivered
☐ Record retention configured
☐ Access controls configured
☐ Amendment notification configured
☐ 30-day Client Agreement notice capability configured where applicable
☐ Accessibility reviewed
☐ Corporate authority flow configured
☐ Disputed signature procedure implemented
☐ Consent withdrawal process implemented
☐ Privacy notice aligned
☐ Security testing completed
SCHEDULE 16
ELECTRONIC COMMUNICATION CONSENT
By selecting the acceptance control, I confirm:
☐ I can access electronic documents.
☐ I can read or download documents presented to me.
☐ I consent to receive ARCBDS contractual and service communications electronically.
☐ I consent to enter applicable ARCBDS agreements electronically.
☐ I understand that my electronic acceptance may create legally binding obligations.
☐ I understand that ARCBDS may retain evidence of my acceptance, including document version, timestamp and authentication records.
☐ I understand that electronic records may be used as evidence subject to Applicable Law.
☐ I will maintain accurate email and mobile contact details.
☐ I will protect my Account, password, MFA and OTP credentials.
☐ I understand that optional marketing consent is separate.
☐ I understand that I may request withdrawal of future electronic consent, but doing so will not cancel or invalidate previous valid transactions or agreements.
☐ I agree to this ARCBDS Electronic Communications & E-Sign Consent.
FINAL ELECTRONIC CONSENT STATEMENT
ARCBDS is designed as a digital-first ecosystem.
Electronic contracting enables Participants to:
review documents;
acknowledge risks;
complete KYC;
submit participation;
verify transactions;
receive allocations;
retain agreements; and
manage communications
through a secure digital process.
Electronic convenience does not reduce the importance of the documents you accept.
Before selecting “I Agree”, you should read the applicable document.
Before entering an OTP, you should verify what you are authorising.
Before signing electronically, you should understand that your action may create a binding legal obligation.
END OF ARCBDS ELECTRONIC COMMUNICATIONS & E-SIGN CONSENT