Payment, Allocation & Blockchain Transaction Policy
ARCBDS PAYMENT, ALLOCATION & BLOCKCHAIN TRANSACTION POLICY
Document No.: 9 of 14
Version: 1.0
Effective Date: [●]
Last Updated: [●]
Policy Owner: Operations / Finance / Compliance
Approved By: [●]
1. INTRODUCTION
This ARCBDS Payment, Allocation & Blockchain Transaction Policy governs the operational handling of:
Founding Circle Contributions;
accepted payment assets;
supported blockchain networks;
official receiving wallets;
transaction verification;
ARCBDS allocation calculations;
Alignment Rewards;
blockchain confirmations;
wallet registration;
token releases;
token distributions;
transaction fees;
incorrect transfers;
rejected Contributions;
refunds;
reconciliation;
transaction records;
transaction disputes; and
related blockchain operations.
This Policy forms part of the ARCBDS Founding Circle legal documentation framework.
2. PURPOSE
The purpose of this Policy is to establish transparent rules governing the movement of value between ARCBDS and Participants.
The objectives are to:
a. protect Participants from incorrect transactions;
b. ensure Contributions are accurately recorded;
c. establish transparent allocation calculations;
d. prevent unauthorised wallet usage;
e. define blockchain confirmation requirements;
f. distinguish submitted transactions from accepted participation;
g. establish rules for failed or incorrect transfers;
h. maintain complete transaction records;
i. support AML/CFT and sanctions compliance;
j. define token-release procedures;
k. establish reconciliation controls; and
l. provide procedures for transaction disputes.
3. RELATIONSHIP WITH OTHER DOCUMENTS
This Policy should be read together with:
ARCBDS Founding Circle Participation Agreement;
ARCBDS Founding Circle Terms & Conditions;
ARCBDS Risk Disclosure Statement;
ARCBDS Participant Protection Reserve Terms;
ARCBDS Website Terms of Use;
ARCBDS Privacy Policy;
ARCBDS KYC, AML & Sanctions Policy;
this Payment, Allocation & Blockchain Transaction Policy;
ARCBDS Cancellation & Refund Policy;
ARCBDS Eligibility & Restricted Jurisdiction Policy;
ARCBDS Electronic Communications & E-Sign Consent; and
other applicable ARCBDS documents.
If this Policy conflicts with the Founding Circle Participation Agreement, the Participation Agreement shall prevail.
4. DEFINITIONS
For purposes of this Policy:
4.1 “Accepted Contribution”
means a Contribution that has successfully passed transaction, compliance and operational verification and has been formally accepted by ARCBDS.
4.2 “Alignment Reward”
means additional ARCBDS allocated according to the Participant's applicable Founding Circle category.
4.3 “Allocation Price”
means the fixed price used to calculate base ARCBDS entitlement for the applicable Founding Circle category.
4.4 “Blockchain Confirmation”
means the confirmation of a transaction by the applicable distributed-ledger network.
4.5 “Contribution”
means digital assets or another approved payment asset transmitted for purposes of applying to participate in the Founding Circle.
4.6 “Designated Receiving Wallet”
means an official wallet address authorised by ARCBDS to receive a particular asset on a particular blockchain network.
4.7 “Final Allocation”
means the confirmed ARCBDS entitlement stated in the Participant's Participation Confirmation.
4.8 “Manifest Error”
means an obvious clerical, calculation, coding, duplication or system error that a reasonable person would recognise as inconsistent with the agreed commercial terms.
4.9 “Official Platform”
means www.arcbds.com and any authorised ARCBDS participation portal.
4.10 “Participation Confirmation”
means the official record confirming an accepted Founding Circle participation.
4.11 “Released ARCBDS”
means ARCBDS that has completed the applicable release requirements.
4.12 “Transaction Hash”
means the unique blockchain transaction identifier associated with an on-chain transaction.
4.13 “Unreleased ARCBDS”
means ARCBDS subject to an applicable Cliff, release schedule or other contractual release restriction.
4.14 “USDT”
means Tether USD on a blockchain network expressly supported by the Official Platform.
5. ACCEPTED PAYMENT ASSET
The principal digital asset intended for Founding Circle Contributions is:
USDT
Only supported versions of USDT displayed on the Official Platform may be used.
ARCBDS may add, remove or temporarily suspend payment assets where operationally, commercially, technically or legally necessary.
6. SUPPORTED BLOCKCHAIN NETWORKS
Subject to final technical deployment, ARCBDS may support USDT on:
TRON
USDT — TRC20
Ethereum
USDT — ERC20
BNB Smart Chain
USDT — BEP20
Additional networks may be added through the Official Platform.
A network must not be considered supported merely because USDT technically exists on that network.
7. OFFICIAL PAYMENT INFORMATION
Participants must obtain payment instructions from an official ARCBDS participation interface.
Official payment information should identify:
a. payment asset;
b. blockchain network;
c. wallet address;
d. amount due;
e. transaction expiry where applicable;
f. payment reference where applicable;
g. network-fee responsibility; and
h. relevant warnings.
8. OFFICIAL RECEIVING WALLETS
ARCBDS shall maintain a controlled register of authorised receiving wallets.
The register should include:
a. wallet address;
b. blockchain;
c. asset;
d. purpose;
e. wallet owner or custodian;
f. authorisation status;
g. activation date;
h. deactivation date;
i. responsible personnel; and
j. relevant security controls.
Participants should send Contributions only to a Designated Receiving Wallet displayed through an official ARCBDS channel.
9. UNOFFICIAL PAYMENT ADDRESSES
Participants must not send Founding Circle Contributions to:
a. personal wallets belonging to community leaders;
b. personal wallets belonging to employees;
c. personal wallets belonging to referrers;
d. social-media wallet addresses not confirmed by the Official Platform;
e. unofficial OTC agents;
f. third-party marketing representatives; or
g. another address not officially designated for the transaction.
Payment to an unauthorised address may not constitute payment to ARCBDS.
10. PAYMENT INSTRUCTIONS
Before sending a Contribution, the Participant is responsible for verifying:
a. the official domain;
b. payment asset;
c. blockchain network;
d. receiving address;
e. amount;
f. applicable network fee; and
g. transaction information.
Blockchain transactions may be irreversible.
11. PAYMENT REQUEST EXPIRY
Where the Platform generates a transaction-specific payment request, that request may have an expiry period.
Payment Request Validity: [●]
A transaction sent after expiry may require manual verification.
Expiry does not necessarily mean that blockchain funds disappear or are automatically refunded.
12. PARTICIPATION CURRENCY
Founding Circle Allocation Prices are denominated in:
United States Dollars (USD)
Contributions may be settled using approved USDT.
USDT is used as a payment instrument and does not change the denomination of the Allocation Price.
13. USDT VALUE FOR ALLOCATION PURPOSES
Unless otherwise disclosed before payment, ARCBDS intends to treat:
1 USDT = US$1.00
for administrative calculation of Founding Circle Contributions.
This is a contractual allocation-calculation convention and does not constitute a guarantee that USDT will always trade at US$1.00 in the market.
14. MATERIAL USDT DE-PEG
If USDT materially deviates from its intended US-dollar value, ARCBDS may temporarily:
a. suspend new USDT Contributions;
b. display an adjusted valuation methodology;
c. require another supported settlement asset;
d. delay acceptance until market conditions stabilise; or
e. implement another disclosed method permitted by Applicable Law.
Any changed valuation method must be disclosed before the affected Contribution is accepted.
ARCBDS shall not retroactively change the valuation of an already accepted Contribution merely because USDT subsequently moves in price.
15. MINIMUM PARTICIPATION
The current minimum Founding Circle Stage 1 Contribution is:
US$100 equivalent
unless a higher amount is required because of:
a. jurisdiction;
b. regulatory classification;
c. transaction channel;
d. institutional participation requirements; or
e. another disclosed condition.
16. CONTRIBUTION LIMITS
ARCBDS may establish:
a. minimum Contribution limits;
b. maximum transaction limits;
c. daily limits;
d. cumulative limits;
e. Participant-specific limits;
f. jurisdiction-specific limits; and
g. compliance-based limits.
Larger Contributions may require Enhanced Due Diligence.
17. CONTRIBUTION PROCESS
The standard Contribution process is:
Step 1 — Register Account
↓
Step 2 — Complete KYC/KYB
↓
Step 3 — Select Participation Category
↓
Step 4 — Review Legal Documents
↓
Step 5 — Accept Required Agreements
↓
Step 6 — Receive Official Payment Instructions
↓
Step 7 — Verify Asset, Network and Address
↓
Step 8 — Transmit Contribution
↓
Step 9 — Blockchain Confirmation
↓
Step 10 — AML / Wallet / Transaction Verification
↓
Step 11 — Reconciliation
↓
Step 12 — Contribution Acceptance
↓
Step 13 — ARCBDS Allocation Calculation
↓
Step 14 — Participation Confirmation
18. PAYMENT DOES NOT EQUAL ACCEPTANCE
Sending USDT to a Designated Receiving Wallet does not by itself guarantee participation.
Participation is accepted only after:
a. KYC/KYB requirements are satisfied;
b. AML and sanctions checks are satisfied;
c. blockchain transaction verification is completed;
d. the payment amount is reconciled;
e. allocation capacity remains available;
f. eligibility requirements are met; and
g. ARCBDS issues a Participation Confirmation or equivalent final acceptance.
19. PENDING CONTRIBUTIONS
A Contribution may be classified as:
Pending Blockchain Confirmation;
Pending Compliance Review;
Pending Reconciliation;
Pending Source-of-Funds Review;
Pending Manual Review; or
another appropriate status.
A pending Contribution is not yet a Final Allocation.
20. BLOCKCHAIN CONFIRMATION REQUIREMENTS
A Contribution must receive sufficient Blockchain Confirmations before it is treated as technically received.
Required confirmations may vary between:
a. TRON;
b. Ethereum;
c. BNB Smart Chain; and
d. other supported networks.
Current technical confirmation requirements shall be maintained in the Platform configuration.
21. CONFIRMATION THRESHOLDS
Internal confirmation thresholds should be determined based on:
a. blockchain characteristics;
b. transaction value;
c. reorganisation risk;
d. network security;
e. operational risk; and
f. provider requirements.
Indicative configuration:
TRC20: [●] confirmations
ERC20: [●] confirmations
BEP20: [●] confirmations
The Platform should display transaction status clearly.
22. BLOCKCHAIN FINALITY
A transaction may appear on a blockchain before ARCBDS regards it as operationally final.
A transaction may remain pending until required confirmations have occurred.
The Participant acknowledges that:
a. blockchain processing may be delayed;
b. network confirmation times vary;
c. ARCBDS does not control public blockchain validators;
d. temporary blockchain reorganisations may occur; and
e. final settlement may occur later than transaction submission.
23. TRANSACTION RECEIPT
Following detection of a Contribution, ARCBDS should provide or make available a transaction record containing appropriate information such as:
a. Participant ID;
b. transaction status;
c. transaction date/time;
d. asset;
e. network;
f. amount detected;
g. receiving wallet;
h. Transaction Hash;
i. network fee where available;
j. confirmation status;
k. compliance status where appropriate; and
l. support contact.
24. ACCEPTANCE RECEIPT
Once a Contribution is accepted, the Participant should receive a Participation Confirmation containing at minimum:
a. Participant name or ID;
b. Contribution amount;
c. accepted USD-equivalent amount;
d. Participation Category;
e. Allocation Price;
f. base ARCBDS allocation;
g. Alignment Reward percentage;
h. Alignment Reward allocation;
i. total ARCBDS entitlement;
j. transaction hash;
k. payment network;
l. agreement version;
m. acceptance date/time;
n. applicable Cliff;
o. applicable participation/release information; and
p. unique Participation Confirmation number.
25. STAGE 1 PARTICIPATION CATEGORIES
ACCESS
Fixed Allocation Price: US$0.095
Alignment Reward: +10%
Participation Period: 9 months
Cliff: None
Release: Linear daily
GROWTH
Fixed Allocation Price: US$0.090
Alignment Reward: +20%
Participation Period: 18 months
Cliff: 3 months
Release: Linear daily according to the approved release schedule
LEGACY
Fixed Allocation Price: US$0.080
Alignment Reward: +30%
Participation Period: 24 months
Cliff: 6 months
Release: Linear daily according to the approved release schedule
26. BASE ARCBDS CALCULATION
The base ARCBDS allocation shall generally be calculated as:
Accepted Contribution ÷ Allocation Price = Base ARCBDS
Example:
A Participant makes an Accepted Contribution of:
US$1,000
and selects Access at:
US$0.095 per ARCBDS
Calculation:
1,000 ÷ 0.095 = 10,526.315789 ARCBDS
subject to the Platform's approved decimal precision.
27. ALIGNMENT REWARD CALCULATION
Alignment Reward is calculated as:
Base ARCBDS × Alignment Reward Percentage
For the Access example:
10,526.315789 × 10% = 1,052.631579 ARCBDS
28. TOTAL ENTITLEMENT
Total ARCBDS entitlement is calculated as:
Base ARCBDS + Alignment Reward ARCBDS
Using the same example:
10,526.315789 + 1,052.631579
=
11,578.947368 ARCBDS
subject to approved rounding rules.
29. GROWTH EXAMPLE
For an Accepted Contribution of US$1,000:
Allocation Price:
US$0.090
Base ARCBDS:
1,000 ÷ 0.090 = 11,111.111111 ARCBDS
Alignment Reward:
11,111.111111 × 20% = 2,222.222222 ARCBDS
Total entitlement:
13,333.333333 ARCBDS
subject to rounding.
30. LEGACY EXAMPLE
For an Accepted Contribution of US$1,000:
Allocation Price:
US$0.080
Base ARCBDS:
12,500 ARCBDS
Alignment Reward:
12,500 × 30% = 3,750 ARCBDS
Total entitlement:
16,250 ARCBDS
31. ALIGNMENT REWARD CHARACTER
Alignment Reward represents additional ARCBDS entitlement.
It is not:
a. interest;
b. cash;
c. guaranteed return;
d. dividend;
e. fixed ROI;
f. guaranteed appreciation; or
g. guaranteed market value.
32. ROUNDING
ARCBDS calculations may require rounding according to the token's technical decimal precision.
The Platform shall use a consistent calculation method.
Rounding should not be manipulated to systematically disadvantage Participants.
33. ROUNDING RULE
Final technical rounding shall be:
ARCBDS Decimal Precision: [●]
Rounding Method: [●]
Intermediate calculations may display more decimal places than final transferable token quantities.
34. STAGE 1 ALLOCATION CAPACITY
The maximum initial Stage 1 entitlement capacity is:
50,000,000 ARCBDS
within an overall Founding Circle allocation of:
200,000,000 ARCBDS
Unless final approved documentation states otherwise, Stage 1 entitlement capacity includes:
a. base allocations; and
b. Alignment Reward allocations.
35. ALLOCATION AVAILABILITY
Submitting a payment does not guarantee allocation if:
a. Stage 1 has already reached capacity;
b. participation has closed;
c. the transaction arrived after a published closing time;
d. the Participant is ineligible; or
e. acceptance is prohibited by law.
Where a Contribution cannot be accepted, it shall be handled according to this Policy and the Cancellation & Refund Policy.
36. OVERSUBSCRIPTION
If valid Contributions collectively exceed remaining Stage 1 capacity, ARCBDS may apply an announced allocation methodology such as:
a. transaction acceptance order;
b. timestamp priority;
c. pro-rata allocation;
d. partial acceptance with refund of excess; or
e. another fair disclosed method.
The methodology used should be documented.
37. TRANSACTION TIMESTAMP
For blockchain Contributions, relevant timestamps may include:
a. transaction broadcast time;
b. blockchain inclusion time;
c. required-confirmation completion time;
d. Platform detection time;
e. compliance clearance time; and
f. final acceptance time.
For allocation priority, the applicable timestamp shall be the one stated in the relevant programme rules.
Where no special rule exists, ARCBDS should apply a consistent and documented method.
38. UNDERPAYMENT
An underpayment occurs where the amount received is below the amount required for the selected participation request.
ARCBDS may:
a. request the Participant to pay the shortfall;
b. adjust the participation amount to the actual Accepted Contribution where permitted;
c. reject the transaction if below the minimum amount; or
d. refund the amount according to applicable rules.
39. OVERPAYMENT
An overpayment occurs where the amount received exceeds the selected participation amount.
ARCBDS may:
a. allocate based on the full eligible Accepted Contribution;
b. return the excess;
c. request Participant confirmation; or
d. apply another disclosed method,
subject to:
programme capacity;
KYC/AML limits;
Participation Category rules; and
Applicable Law.
40. DUPLICATE PAYMENTS
Where a Participant unintentionally submits the same Contribution more than once, ARCBDS shall determine whether the additional transaction should be:
a. treated as an additional participation;
b. held pending Participant instructions;
c. refunded; or
d. otherwise resolved.
Compliance requirements continue to apply.
41. SMALL EXCESS AMOUNTS
ARCBDS may establish a de minimis operational threshold for small accidental excess amounts.
Threshold: [●]
Any such threshold must be disclosed and administered fairly.
42. UNSUPPORTED ASSETS
Participants must not send assets other than those expressly supported.
Examples of unsupported transfers may include:
a. another stablecoin;
b. native network tokens;
c. wrapped assets;
d. NFTs;
e. unsupported USDT versions; or
f. other tokens.
Recovery is not guaranteed.
43. WRONG NETWORK TRANSFERS
A wrong-network transfer occurs where an otherwise recognised asset is sent through a network that ARCBDS does not support for that receiving address.
Such assets may be:
a. inaccessible;
b. technically recoverable;
c. permanently lost; or
d. recoverable only through specialised procedures.
ARCBDS does not guarantee recovery.
44. INCORRECT WALLET ADDRESS
Blockchain transactions sent to an address not controlled by ARCBDS may be impossible for ARCBDS to recover.
The Participant is responsible for verifying the receiving address before transaction authorisation.
ARCBDS cannot reverse a transaction on a public blockchain merely because the sender made an error.
45. RECOVERY REQUEST
Where a mistaken transaction may be recoverable, the Participant may submit a Recovery Request containing:
a. Participant ID;
b. Transaction Hash;
c. asset;
d. blockchain;
e. amount;
f. sending wallet;
g. intended receiving wallet;
h. proof of ownership;
i. explanation; and
j. other requested evidence.
46. RECOVERY IS DISCRETIONARY WHERE NOT LEGALLY REQUIRED
Technical recovery may be refused where:
a. private-key access is unavailable;
b. recovery could compromise security;
c. required infrastructure does not support recovery;
d. the amount is below reasonable recovery cost;
e. sanctions or AML concerns exist;
f. ownership cannot be established; or
g. recovery is technically impossible.
47. RECOVERY FEES
Where recovery requires extraordinary technical work, ARCBDS may charge a reasonable recovery fee if:
a. disclosed before recovery proceeds;
b. the fee reflects reasonable costs;
c. the Participant accepts it; and
d. Applicable Law permits it.
Recovery Fee Schedule: [●]
48. NETWORK FEES
Unless expressly stated otherwise, the sender is responsible for blockchain network fees required to transmit a Contribution.
The amount received by ARCBDS after applicable network deductions, if any, will be used for reconciliation.
49. TOKEN DISTRIBUTION FEES
The treatment of network fees associated with ARCBDS distributions or withdrawals shall be disclosed by the Platform.
Possible structures include:
a. ARCBDS bears the fee;
b. Participant bears the fee;
c. fee deducted from transferable balance; or
d. another disclosed method.
Current Distribution Fee Policy: [●]
50. NO HIDDEN FEES
ARCBDS should disclose material fees before the relevant transaction is authorised.
No fee should be hidden inside an unexplained allocation adjustment.
51. FEE SCHEDULE
The current fee schedule should identify:
Fee
Amount / Method
Founding Circle Participation Fee
[None / ●]
Blockchain Incoming Network Fee
Paid by sender/network
ARCBDS Distribution Fee
[●]
Withdrawal Fee
[●]
Recovery Fee
[●]
Refund Network Fee
[●]
Other Fee
[●]
Changes shall be handled according to Applicable Law and applicable agreements.
52. THIRD-PARTY PAYMENTS
Participants should ordinarily fund participation from a wallet or account:
a. owned by them; or
b. otherwise accepted following verification.
Third-party payments may require Enhanced Due Diligence.
53. THIRD-PARTY FUNDING VERIFICATION
Where a Contribution originates from another person, ARCBDS may request:
a. payer identity;
b. payer KYC;
c. relationship to Participant;
d. reason for funding;
e. source of funds;
f. wallet ownership evidence; and
g. written authorisation.
ARCBDS may reject third-party funding.
54. RETURN TO ORIGINAL SOURCE
Where a refund is approved, ARCBDS will generally seek to return funds to the original verified funding source where legally and technically appropriate.
This reduces the risk of ARCBDS being used to redirect or launder assets.
55. NO REFUNDS TO UNRELATED THIRD PARTIES
ARCBDS will not ordinarily redirect a refund to an unrelated third-party wallet merely because the Participant requests it.
Exceptions require Compliance approval and appropriate verification.
56. AML AND SANCTIONS SCREENING
Contributions may be screened for exposure to:
a. sanctions;
b. fraud;
c. stolen assets;
d. ransomware;
e. hacks;
f. darknet markets;
g. terrorist-financing indicators;
h. mixers;
i. scams;
j. high-risk services; and
k. other financial-crime indicators.
A transaction may be delayed while screening is completed.
57. TRANSACTION HOLD
ARCBDS may place a transaction on hold where:
a. KYC is incomplete;
b. sanctions concerns exist;
c. wallet-risk indicators exist;
d. source of funds requires verification;
e. transaction amount is inconsistent with Participant profile;
f. fraud is suspected;
g. beneficial ownership is unclear; or
h. Applicable Law requires review.
58. SANCTIONS FREEZE
Where Applicable Law requires assets to be frozen:
a. the transaction may not be returned;
b. allocation may not proceed;
c. transfer may be prohibited;
d. disclosure may be restricted; and
e. ARCBDS shall comply with competent authority requirements.
59. TRAVEL RULE
Where a transaction falls within applicable Travel Rule requirements, ARCBDS may request or transmit required originator and beneficiary information.
Failure to provide required information may result in:
a. delay;
b. rejection;
c. return where lawful; or
d. compliance escalation.
60. ALLOCATION RECORD
For every Final Allocation, ARCBDS should maintain a record containing:
a. Participant ID;
b. transaction hash;
c. accepted Contribution;
d. USD-equivalent amount;
e. Participation Category;
f. Allocation Price;
g. base ARCBDS;
h. Alignment Reward;
i. total entitlement;
j. release schedule;
k. acceptance date;
l. legal-document versions; and
m. responsible system reference.
61. PARTICIPATION CONFIRMATION CONTROLS
A Participation Confirmation should receive a unique reference number.
Once issued, the record should not be altered without:
a. authorised correction;
b. audit trail;
c. reason for correction;
d. responsible person/system; and
e. Participant notification where material.
62. ALLOCATION CORRECTIONS
ARCBDS may correct a Manifest Error.
Examples include:
a. duplicated allocation;
b. wrong category applied;
c. mathematical error;
d. incorrect decimal placement;
e. incorrect payment amount imported;
f. duplicate Alignment Reward; or
g. system malfunction.
63. NO ARBITRARY REDUCTION
ARCBDS shall not arbitrarily reduce:
a. an accepted Allocation Price;
b. confirmed base allocation;
c. confirmed Alignment Reward percentage; or
d. confirmed entitlement
after acceptance merely because later commercial terms change.
64. MANIFEST WINDFALL ERROR
If a system obviously credits a Participant with an allocation materially greater than contractually due, the Participant does not obtain an unconditional contractual right to retain the excess solely because it appeared on a dashboard.
ARCBDS may correct the Manifest Error subject to an appropriate audit record.
65. MANIFEST SHORTFALL ERROR
If a system credits less ARCBDS than contractually due, ARCBDS shall correct the shortfall after verification.
A Participant should not lose entitlement because of a proven internal calculation error.
66. ALLOCATION DISPUTES
A Participant who believes an allocation is incorrect should notify ARCBDS within:
[7] calendar days
after receiving the Participation Confirmation, or another period required by Applicable Law.
Failure to notify within that period does not eliminate a mandatory legal right or the right to correct a proven Manifest Error.
67. RELEASE SCHEDULE
ARCBDS allocations shall be subject to the release structure applicable to the selected Participation Category.
The Participant's Participation Confirmation shall state:
a. allocation date;
b. Cliff, if any;
c. release commencement;
d. applicable release period;
e. release calculation method; and
f. expected final release date.
68. RELEASE-SCHEDULE CLARITY
For Growth and Legacy, the final system implementation must expressly identify whether the applicable 18-month or 24-month Participation Period includes the stated Cliff within that total period or whether the release schedule operates differently.
No undisclosed extension of a Participant's release period may be imposed through backend configuration.
The Participant-specific Participation Confirmation shall control once the approved release structure has been finalised.
69. DAILY LINEAR RELEASE
Where a linear daily release applies, the amount scheduled for release should be determined using the approved release formula.
Indicative formula:
Total Releasable ARCBDS ÷ Number of Applicable Release Days
subject to:
a. Cliff;
b. decimal precision;
c. leap-year/calendar handling;
d. smart-contract architecture; and
e. final approved release schedule.
70. RELEASE TIMESTAMP
The Platform should apply a consistent release timezone and timestamp.
Official Release Timezone: [UTC / UTC+8 / ●]
Release Calculation Time: [●]
The timezone must be disclosed to Participants.
71. DASHBOARD DISPLAY
The Participant dashboard may display:
a. Total Entitlement;
b. Base Allocation;
c. Alignment Reward;
d. Released ARCBDS;
e. Unreleased ARCBDS;
f. next scheduled release;
g. release progress;
h. wallet status;
i. transaction history; and
j. other relevant information.
72. DISPLAY DOES NOT CHANGE CONTRACTUAL ENTITLEMENT
A temporary dashboard display error does not alter the Participant's legally valid entitlement.
Entitlement shall be determined using the reconciliation hierarchy in Section 96.
73. RELEASED ARCBDS
Once ARCBDS becomes Released ARCBDS, it may become available for:
a. Platform use;
b. withdrawal;
c. transfer;
d. ecosystem functions; or
e. other legally permitted functions,
subject to technical availability, compliance and Applicable Law.
74. UNRELEASED ARCBDS
Unreleased ARCBDS may not ordinarily be:
a. withdrawn;
b. transferred;
c. sold;
d. pledged;
e. assigned; or
f. used as collateral
unless expressly permitted.
75. WALLET REGISTRATION
Participants may be required to register a withdrawal or receiving wallet.
The Participant is responsible for ensuring the wallet:
a. is correct;
b. is compatible;
c. supports the relevant network;
d. is legally controlled by the Participant; and
e. satisfies Compliance requirements.
76. WALLET WHITELISTING
ARCBDS may implement wallet whitelisting for security.
A newly added wallet may require:
a. OTP;
b. MFA;
c. email confirmation;
d. identity verification;
e. wallet signature;
f. security review; or
g. cooling period.
77. WALLET CHANGE
A Participant requesting a wallet change may be required to complete enhanced verification.
ARCBDS may temporarily restrict withdrawals following a material security change.
This is intended to reduce Account takeover risk.
78. WALLET-CHANGE COOLING PERIOD
Where implemented:
Wallet Change Cooling Period: [●]
Higher-value transfers may require additional approval.
79. WITHDRAWAL AUTHENTICATION
Withdrawals may require:
a. authenticated login;
b. MFA;
c. OTP;
d. transaction confirmation;
e. risk-based challenge;
f. wallet verification; and
g. compliance screening.
80. WITHDRAWAL LIMITS
ARCBDS may maintain risk-based withdrawal limits.
Indicative categories:
Standard Daily Limit: [●]
Enhanced Verified Limit: [●]
Manual Approval Threshold: [●]
Limits may vary based on:
a. KYC status;
b. Participant risk;
c. transaction history;
d. security factors;
e. legal requirements; and
f. operational controls.
81. HIGH-VALUE TRANSACTIONS
Higher-value transactions may require:
a. additional authentication;
b. manual approval;
c. source-of-funds review;
d. wallet verification;
e. call-back verification; or
f. additional cooling periods.
82. BLOCKCHAIN DISTRIBUTION
Where Released ARCBDS is distributed on-chain, ARCBDS should record:
a. Participant ID;
b. destination wallet;
c. amount;
d. blockchain network;
e. transaction hash;
f. submission time;
g. confirmation time;
h. transaction status; and
i. fees.
83. FAILED DISTRIBUTION
A distribution may fail because of:
a. invalid address;
b. unsupported network;
c. network congestion;
d. smart-contract failure;
e. insufficient network fee;
f. security restriction;
g. sanctions restriction;
h. Platform outage; or
i. other technical issue.
A failed distribution should be investigated and, where appropriate, retried after the cause is resolved.
84. DELAYED DISTRIBUTION
A delayed distribution does not necessarily constitute loss of entitlement.
ARCBDS shall use reasonable efforts to resolve valid distributions delayed by operational or technical issues.
85. SMART-CONTRACT TRANSACTIONS
If release or distribution is administered using smart contracts:
a. contract addresses shall be controlled and verified;
b. deployment shall follow appropriate approval;
c. code should be tested;
d. security review should be performed;
e. administrative keys should be protected;
f. material upgrades should be governed; and
g. transaction records should be maintained.
86. SMART-CONTRACT ADDRESS
The official ARCBDS token contract address shall be published only after final deployment and verification.
Official Contract Address: [●]
Blockchain: [●]
Token Standard: [●]
Decimals: [●]
Participants must verify the official contract before interacting with ARCBDS.
87. FAKE TOKEN WARNING
Scammers may create tokens using the ARCBDS name.
A token should not be treated as genuine merely because:
a. its name says ARCBDS;
b. its symbol resembles ARCBDS;
c. a social-media user provides a contract address; or
d. it appears on an unofficial decentralised exchange.
Only the contract address published through official ARCBDS channels should be relied upon.
88. BLOCKCHAIN FORKS
If a supported blockchain undergoes a fork, ARCBDS may temporarily suspend:
a. deposits;
b. withdrawals;
c. releases; or
d. other transactions
until network stability and supported-chain treatment are determined.
89. AIRDROPS AND FORKS
ARCBDS does not automatically undertake to support or distribute:
a. forked assets;
b. unsolicited tokens;
c. airdrops;
d. promotional tokens; or
e. other assets
received at operational wallets, unless expressly announced or required by Applicable Law.
90. NETWORK CONGESTION
Blockchain congestion may cause:
a. delayed deposits;
b. delayed withdrawals;
c. higher network fees;
d. delayed transaction confirmation; and
e. temporary suspension of a network.
ARCBDS does not control public blockchain capacity.
91. NETWORK SUSPENSION
ARCBDS may suspend a network because of:
a. blockchain upgrade;
b. security incident;
c. chain instability;
d. hard fork;
e. wallet maintenance;
f. custodian maintenance;
g. regulatory restriction; or
h. material technical risk.
Where possible, users should be informed.
92. TRANSACTION IRREVERSIBILITY
Once a blockchain transfer has achieved sufficient finality, ARCBDS generally cannot reverse the blockchain itself.
Error-resolution procedures may involve a new compensating transaction rather than deletion of the original blockchain record.
93. TRANSACTION RECORDS
ARCBDS shall maintain transaction records appropriate to its legal and operational obligations.
Records may include:
a. transaction instructions;
b. receipts;
c. Transaction Hashes;
d. wallet addresses;
e. asset;
f. amount;
g. network;
h. fees;
i. timestamps;
j. allocation calculation;
k. compliance status;
l. error corrections;
m. refunds;
n. distribution records; and
o. dispute records.
94. RECORD RETENTION
Where applicable regulatory requirements impose an eight-year recordkeeping period, ARCBDS shall retain relevant transaction and receipt records for at least:
Eight (8) Years
or longer where required by:
a. AML laws;
b. regulatory requirements;
c. litigation;
d. sanctions;
e. audit;
f. tax; or
g. another legal hold.
95. RECONCILIATION
ARCBDS shall perform periodic reconciliation between:
a. blockchain transactions;
b. receiving wallets;
c. Participant Account records;
d. allocation system;
e. finance records;
f. token distribution records; and
g. applicable custody records.
Material differences must be investigated.
96. RECORD HIERARCHY
Where records temporarily disagree, the following evidence shall generally be used to determine the correct position:
1. Legally valid Participation Agreement and Participant-specific Participation Confirmation
for agreed commercial entitlement;
2. Verified public blockchain record
for whether an on-chain transfer occurred and the on-chain amount;
3. ARCBDS controlled wallet/custodian record
for receipt or distribution;
4. Authorised finance and allocation ledger
for reconciliation;
5. Platform transaction record
for operational processing;
6. Dashboard display
for user convenience.
A dashboard display alone shall not override stronger verified records.
97. BLOCKCHAIN RECORD INTEGRITY
For an on-chain transaction, a verified blockchain record may establish:
a. originating address;
b. destination address;
c. transaction amount;
d. timestamp/block data;
e. transaction hash; and
f. blockchain status.
However, blockchain data alone may not establish:
a. legal ownership;
b. identity;
c. contractual purpose;
d. KYC status; or
e. entitlement to a particular allocation.
98. PARTICIPANT TRANSACTION HISTORY
Participants should have reasonable access to transaction history through:
a. dashboard;
b. downloadable statement;
c. transaction receipt; or
d. customer support request,
subject to Applicable Law and technical availability.
99. PERIODIC STATEMENTS
Where required by Applicable Law or applicable regulatory status, ARCBDS shall provide periodic Account or transaction statements containing required information.
Statements may show:
a. balances;
b. allocations;
c. credits;
d. debits;
e. releases;
f. distributions;
g. fees; and
h. relevant transaction references.
100. TRANSACTION DISPUTE
A Participant may report:
a. missing Contribution;
b. incorrect allocation;
c. duplicate transaction;
d. missing token distribution;
e. incorrect wallet transfer;
f. wrong fee;
g. dashboard inconsistency;
h. unauthorised transaction; or
i. another transaction issue.
101. DISPUTE INFORMATION
The Participant should provide:
a. Participant ID;
b. Transaction Hash;
c. date;
d. amount;
e. network;
f. sending wallet;
g. receiving wallet;
h. Participation Confirmation where relevant;
i. screenshots where useful; and
j. explanation.
102. INVESTIGATION
ARCBDS may investigate using:
a. blockchain records;
b. Platform logs;
c. wallet logs;
d. custody records;
e. KYC records;
f. security logs;
g. finance ledgers;
h. smart-contract data; and
i. other relevant records.
103. UNAUTHORISED TRANSACTIONS
A reported unauthorised transaction may trigger:
a. Account restriction;
b. password reset;
c. MFA reset;
d. wallet freeze where technically possible;
e. security investigation;
f. blockchain analysis;
g. compliance review; and
h. law-enforcement escalation where appropriate.
104. PARTICIPANT ERROR
Where a loss results from the Participant:
a. disclosing a private key;
b. disclosing a seed phrase;
c. sending to the wrong address;
d. choosing an unsupported network;
e. approving a malicious smart contract; or
f. ignoring clear transaction warnings,
recovery may be impossible.
Nothing in this section excludes liability legally attributable to ARCBDS.
105. ARCBDS ERROR
Where ARCBDS makes a verified operational error, ARCBDS shall take reasonable steps to correct the error.
Depending on the issue, correction may include:
a. adjusting the internal ledger;
b. issuing missing allocation;
c. reprocessing a transfer;
d. refunding an incorrect charge;
e. issuing a compensating transaction; or
f. another appropriate remedy.
106. DUPLICATE TOKEN DISTRIBUTION
Where an obvious technical error results in duplicate distribution, ARCBDS may request return of the duplicate amount or apply lawful corrective procedures.
The Participant should not knowingly exploit a system error.
107. TRANSACTION MONITORING
Transactions remain subject to ongoing monitoring under the KYC, AML & Sanctions Policy.
A transaction that passes technical confirmation may still be held for compliance review.
108. FRAUDULENT TRANSACTIONS
ARCBDS may restrict or reject transactions associated with:
a. stolen credentials;
b. fake Accounts;
c. fraudulent documents;
d. sanctions evasion;
e. stolen digital assets;
f. manipulation;
g. phishing;
h. Account takeover; or
i. other unlawful activity.
109. PROTECTION RESERVE TRANSACTIONS
A Participant Protection Reserve settlement shall be treated as a separate transaction type.
The settlement record should show:
a. Claim ID;
b. Eligible ARCBDS surrendered;
c. Reference Market Price;
d. approved settlement amount;
e. settlement asset;
f. settlement wallet;
g. token surrender Transaction Hash;
h. payment Transaction Hash; and
i. settlement date.
110. PROTECTION RESERVE IS NOT ORDINARY WITHDRAWAL
A Protection Reserve Claim does not create an ordinary withdrawal right.
Claims remain subject to the ARCBDS Participant Protection Reserve Terms.
111. REFUNDS
Refunds shall be governed principally by the ARCBDS Cancellation & Refund Policy.
A refund is not equivalent to:
a. a Protection Reserve Claim;
b. secondary-market sale;
c. token redemption; or
d. guaranteed buyback.
112. REFUND VALUATION
Where a Contribution is rejected before allocation and a refund is legally permitted, the applicable refund methodology shall be determined by the Cancellation & Refund Policy.
Blockchain network fees and changes in stablecoin value may affect the economic amount received by the Participant.
113. NO MARKET PRICE GUARANTEE
The Allocation Price does not guarantee future:
a. exchange price;
b. OTC price;
c. Protection Reserve price;
d. redemption price; or
e. market value.
114. NO GUARANTEED LIQUIDITY
Successful token distribution does not mean a market will exist for the tokens.
The Participant may receive ARCBDS and nevertheless be unable to sell it.
115. NO AUTOMATIC BUYBACK
Nothing in this Policy creates an unconditional right requiring ARCBDS to repurchase a Participant's ARCBDS.
The Protection Reserve is governed separately.
116. ACCOUNT AND WALLET SECURITY
Participants should:
a. use strong passwords;
b. enable MFA;
c. protect email access;
d. verify addresses;
e. protect devices;
f. avoid suspicious links;
g. verify the official domain;
h. never share seed phrases; and
i. never share private keys.
117. ARCBDS WILL NOT REQUEST PRIVATE KEYS
ARCBDS personnel must not request:
a. private keys;
b. recovery phrases;
c. seed phrases; or
d. complete wallet-control credentials.
A request for such information should be treated as suspected fraud.
118. TRANSACTION NOTIFICATIONS
Where technically supported, ARCBDS may send notifications relating to:
a. Contribution detection;
b. Contribution confirmation;
c. allocation;
d. release;
e. wallet changes;
f. withdrawals;
g. failed transactions;
h. refunds; and
i. security events.
119. ELECTRONIC RECORDS
Transaction confirmations and receipts may be delivered electronically.
Electronic records may constitute official records subject to the ARCBDS Electronic Communications & E-Sign Consent.
120. DATA PROTECTION
Transaction information may constitute Personal Data.
ARCBDS shall process such information according to the ARCBDS Privacy Policy.
Public blockchain records may remain permanently accessible even after an ARCBDS Account is closed.
121. OPERATIONAL SECURITY
ARCBDS shall implement reasonable controls for operational wallets, which may include:
a. multi-signature controls;
b. role separation;
c. approval thresholds;
d. cold storage;
e. hardware security;
f. address whitelisting;
g. transaction limits;
h. monitoring;
i. access logging;
j. key backup; and
k. incident response.
The exact architecture shall be determined by the final custody and wallet structure.
122. SEGREGATION OF CLIENT ASSETS WHERE APPLICABLE
Where ARCBDS or an authorised entity holds Virtual Assets that legally constitute Client Virtual Assets rather than accepted Company consideration, such assets shall be handled according to applicable client-asset requirements.
This may require:
a. segregation from Company assets;
b. client-wallet identification;
c. one-to-one holdings;
d. reconciliation;
e. restrictions on rehypothecation; and
f. appropriate custody controls.
The legal treatment of each asset flow must be determined before launch.
123. PENDING FUNDS
Where a Contribution has been received but has not yet been accepted, ARCBDS shall maintain clear accounting and operational records identifying its status.
The final operating model should define whether pending funds constitute:
a. client assets;
b. funds pending acceptance;
c. conditional contractual consideration; or
d. another legally recognised category.
This classification must be confirmed by legal counsel and the applicable regulator.
124. CUSTODY
If a third-party custodian is appointed:
Custodian: [●]
Jurisdiction: [●]
Regulatory Status: [●]
Custody Scope: [●]
Participants shall receive applicable custody disclosures before the relevant service is used.
125. BUSINESS CONTINUITY
ARCBDS should maintain procedures for transaction processing during:
a. Platform outage;
b. wallet outage;
c. blockchain outage;
d. custodian outage;
e. cybersecurity incident;
f. power failure;
g. cloud-provider disruption; and
h. other operational incidents.
126. EMERGENCY SUSPENSION
ARCBDS may suspend transactions where reasonably necessary to protect:
a. Participants;
b. Company assets;
c. Client Virtual Assets where applicable;
d. blockchain infrastructure;
e. regulatory compliance; or
f. ecosystem integrity.
Suspension should be no broader or longer than reasonably necessary.
127. INCIDENT COMMUNICATION
Where a material transaction incident occurs, ARCBDS should communicate appropriate information where legally permitted, including:
a. affected service;
b. current status;
c. Participant action required;
d. security precautions; and
e. resolution updates.
Confidential security information need not be publicly disclosed.
128. REGULATORY ACTION
ARCBDS may restrict transactions where required by:
a. regulator;
b. court;
c. sanctions authority;
d. law enforcement;
e. competent governmental authority; or
f. Applicable Law.
Such action may override ordinary processing timelines.
129. FORCE MAJEURE
Transactions may be delayed by events beyond reasonable control, including:
a. blockchain failure;
b. widespread cyberattack;
c. exchange failure;
d. stablecoin disruption;
e. infrastructure failure;
f. war;
g. government action;
h. sanctions;
i. natural disaster; or
j. other comparable events.
130. CHANGES TO SUPPORTED NETWORKS
ARCBDS may add or remove supported blockchain networks.
Removal should be announced where reasonably possible before it takes effect.
Existing valid transactions shall be handled according to their applicable terms.
131. CHANGES TO PAYMENT ASSETS
ARCBDS may add, suspend or remove payment assets where permitted.
New payment assets must undergo appropriate:
a. legal review;
b. compliance review;
c. technical review;
d. cybersecurity review;
e. liquidity assessment; and
f. operational approval.
132. CHANGES TO THIS POLICY
This Policy may be amended because of:
a. regulatory requirements;
b. blockchain changes;
c. custody changes;
d. payment-method changes;
e. security developments;
f. Platform upgrades;
g. operational improvements; or
h. other legitimate reasons.
Material changes affecting existing contractual rights shall be handled according to the Participation Agreement and Applicable Law.
133. VERSION CONTROL
ARCBDS shall maintain records of:
a. Policy version;
b. effective date;
c. prior versions;
d. material changes;
e. system configuration;
f. fee schedule;
g. supported network list; and
h. applicable Participant records.
134. COMPLAINTS
Payment, allocation or transaction complaints may be submitted through:
Transaction Support: [●]
Compliance: [●]
Complaints: [●]
Website: www.arcbds.com
The Participant should provide relevant transaction information.
135. GOVERNING LAW
This Policy shall be governed by the same governing law applicable to the ARCBDS Founding Circle Participation Agreement.
Final Governing Law: [●]
136. DISPUTE RESOLUTION
Disputes concerning payment, allocation or blockchain transactions shall follow the dispute-resolution mechanism contained in the Founding Circle Participation Agreement.
Nothing in this Policy removes mandatory rights that cannot legally be waived.
SCHEDULE 1
SUPPORTED PAYMENT METHODS
Asset
Network
Standard
Status
USDT
TRON
TRC20
Intended Supported
USDT
Ethereum
ERC20
Intended Supported
USDT
BNB Smart Chain
BEP20
Intended Supported
[●]
[●]
[●]
[●]
Only networks displayed as active on the Official Platform at the time of payment are considered supported.
SCHEDULE 2
STAGE 1 ALLOCATION TERMS
Term
Access
Growth
Legacy
Minimum Participation
US$100
US$100
US$100
Allocation Price
US$0.095
US$0.090
US$0.080
Alignment Reward
+10%
+20%
+30%
Participation Period
9 Months
18 Months
24 Months
Cliff
None
3 Months
6 Months
Release
Linear Daily
Linear Daily
Linear Daily
Stage 1 Entitlement Capacity
50,000,000 ARCBDS
Overall Founding Circle Allocation
200,000,000 ARCBDS
Technical Release Configuration
Access Release Start: [●]
Growth Release Start: [●]
Growth Final Release: [●]
Legacy Release Start: [●]
Legacy Final Release: [●]
These fields must exactly match the approved commercial structure and Platform implementation before launch.
SCHEDULE 3
PARTICIPATION CALCULATION
Formula
Base Allocation
Accepted Contribution ÷ Allocation Price
Alignment Reward
Base Allocation × Reward %
=
Total ARCBDS Entitlement
Example — Access
Contribution: US$1,000
Allocation Price: US$0.095
Base: 10,526.315789
Reward: 1,052.631579
Total: 11,578.947368 ARCBDS
Example — Growth
Contribution: US$1,000
Allocation Price: US$0.090
Base: 11,111.111111
Reward: 2,222.222222
Total: 13,333.333333 ARCBDS
Example — Legacy
Contribution: US$1,000
Allocation Price: US$0.080
Base: 12,500
Reward: 3,750
Total: 16,250 ARCBDS
SCHEDULE 4
PAYMENT SCREEN
Before payment, the Website should display substantially:
VERIFY BEFORE YOU SEND
Participation Category: [Access / Growth / Legacy]
Contribution: [●] USDT
Network: [TRC20 / ERC20 / BEP20]
Official Receiving Address:
[●]
Allocation Price: US$[●]
Estimated Base ARCBDS: [●]
Alignment Reward: [●]%
Estimated Total Entitlement: [●]
WARNING
Blockchain transactions may be irreversible.
Sending the wrong asset, using an unsupported network or sending to an incorrect address may result in permanent loss.
Always verify the official ARCBDS domain and payment details before sending.
SCHEDULE 5
CONTRIBUTION RECEIPT
Transaction Status: [●]
Participant ID: [●]
Date / Time: [●]
Asset: USDT
Network: [●]
Amount: [●]
Receiving Address: [●]
Transaction Hash: [●]
Confirmations: [●]
Network Fee: [●]
Compliance Status: [●]
Participation Status: Pending / Accepted / Rejected
This receipt confirms transaction detection only unless expressly marked Accepted Participation.
SCHEDULE 6
PARTICIPATION CONFIRMATION
Confirmation No.: [●]
Participant: [●]
Participant ID: [●]
KYC Reference: [●]
Contribution: [●] USDT
USD-Equivalent Accepted: US$[●]
Category: [●]
Allocation Price: US$[●]
Base ARCBDS: [●]
Alignment Reward: [●]%
Reward ARCBDS: [●]
TOTAL ARCBDS ENTITLEMENT: [●]
Cliff: [●]
Release Commencement: [●]
Expected Final Release: [●]
Transaction Hash: [●]
Network: [●]
Agreement Version: [●]
Policy Version: [●]
Acceptance Timestamp: [●]
SCHEDULE 7
WRONG TRANSACTION RECOVERY FORM
Participant ID: [●]
Transaction Hash: [●]
Date: [●]
Asset Sent: [●]
Network Used: [●]
Amount: [●]
Sending Wallet: [●]
Receiving Wallet: [●]
Error Type
☐ Wrong Network
☐ Unsupported Asset
☐ Wrong Amount
☐ Duplicate Payment
☐ Incorrect Address
☐ Missing Reference
☐ Other
Description
[●]
Proof of Ownership
[●]
Recovery Decision
☐ Recoverable
☐ Not Recoverable
☐ Additional Verification Required
Recovery Fee
[●]
SCHEDULE 8
TRANSACTION DISPUTE FORM
Participant: [●]
Participant ID: [●]
Transaction Hash: [●]
Participation Confirmation: [●]
Dispute
☐ Contribution Missing
☐ Contribution Amount Incorrect
☐ Allocation Incorrect
☐ Alignment Reward Incorrect
☐ Token Release Incorrect
☐ Withdrawal Missing
☐ Duplicate Transaction
☐ Incorrect Fee
☐ Unauthorised Transaction
☐ Other
Description
[●]
Supporting Evidence
[●]
Investigation Result
[●]
Corrective Action
[●]
SCHEDULE 9
WALLET CHANGE FORM
Participant ID: [●]
Existing Wallet: [●]
New Wallet: [●]
Blockchain: [●]
Verification
☐ Login Authentication
☐ MFA
☐ OTP
☐ Identity Verification
☐ Wallet Ownership
☐ Compliance Screening
Cooling Period
[●]
Approval
[●]
SCHEDULE 10
OPERATIONAL WALLET REGISTER
Wallet
Network
Asset
Purpose
Control
Status
[●]
TRON
USDT
Contribution
[●]
Active
[●]
Ethereum
USDT
Contribution
[●]
Active
[●]
BSC
USDT
Contribution
[●]
Active
[●]
[●]
ARCBDS
Distribution
[●]
[●]
[●]
[●]
[●]
Protection Reserve
[●]
[●]
The public version of this Policy need not disclose security-sensitive wallet architecture unless legally required.
SCHEDULE 11
RECONCILIATION CHECKLIST
For each reconciliation period:
☐ Blockchain incoming transactions reconciled
☐ Participant Contributions reconciled
☐ Accepted Contributions reconciled
☐ Rejected Contributions reconciled
☐ Refunds reconciled
☐ Stage 1 allocation reconciled
☐ Alignment Rewards reconciled
☐ Released ARCBDS reconciled
☐ Unreleased ARCBDS reconciled
☐ On-chain distributions reconciled
☐ Failed transfers investigated
☐ Protection Reserve transfers reconciled
☐ Wallet balances reconciled
☐ Custodian balances reconciled
☐ Material differences escalated
Reviewer: [●]
Date: [●]
SCHEDULE 12
TRANSACTION STATUS DEFINITIONS
CREATED
Payment request generated.
BROADCAST
Transaction submitted to blockchain.
DETECTED
Transaction detected by ARCBDS infrastructure.
CONFIRMING
Awaiting required Blockchain Confirmations.
COMPLIANCE REVIEW
Transaction subject to AML/KYC review.
RECONCILING
Payment undergoing financial reconciliation.
ACCEPTED
Contribution formally accepted.
ALLOCATED
ARCBDS entitlement calculated and confirmed.
REJECTED
Participation not accepted.
REFUND PENDING
Approved refund awaiting processing.
REFUNDED
Refund completed.
DISTRIBUTION PENDING
ARCBDS transfer pending.
DISTRIBUTED
ARCBDS transfer completed.
FAILED
Technical transaction failure.
SUSPENDED
Processing temporarily restricted.
SCHEDULE 13
PARTICIPANT TRANSACTION ACKNOWLEDGEMENT
Before sending a Contribution, the Participant should confirm:
☐ I have verified the official ARCBDS Website.
☐ I have selected the correct Participation Category.
☐ I have verified the payment asset.
☐ I have verified the blockchain network.
☐ I have verified the receiving wallet address.
☐ I understand blockchain transactions may be irreversible.
☐ I understand that sending payment does not by itself guarantee participation acceptance.
☐ I understand that my Contribution remains subject to KYC, AML and sanctions review.
☐ I understand that the Allocation Price is used for token allocation and does not guarantee future ARCBDS market price.
☐ I understand that the Alignment Reward is additional ARCBDS, not guaranteed financial return.
☐ I understand that unsupported assets or networks may result in loss.
☐ I agree to this Payment, Allocation & Blockchain Transaction Policy.
SCHEDULE 14
INTERNAL TRANSACTION APPROVAL MATRIX
ARCBDS should maintain an internal matrix defining approval requirements by transaction type and value.
Transaction Type
Threshold
Approval
Standard Contribution
[●]
Automated + Compliance
High-Value Contribution
[●]
Enhanced Review
Standard Withdrawal
[●]
Automated Controls
High-Value Withdrawal
[●]
Dual / Manual Approval
Wallet Change + Withdrawal
[●]
Enhanced Verification
Refund
[●]
Operations + Compliance
Large Refund
[●]
Finance + Compliance
Protection Reserve Settlement
[●]
Claims + Compliance
Large Reserve Settlement
[●]
Committee / Senior Approval
Manual Token Adjustment
Any
Dual Approval
Operational Wallet Transfer
[●]
Multi-Approval
No single employee should have unrestricted ability to create, approve and complete material transactions without appropriate controls.
SCHEDULE 15
FINAL TRANSACTION PRINCIPLES
ARCBDS shall administer payment and allocation according to ten core principles:
1. Verify Before Transfer
Participants must receive clear payment information.
2. Use Official Wallets Only
Personal or unofficial wallets must not be used to collect Founding Circle Contributions.
3. Blockchain Confirmation
A broadcast transaction is not necessarily a final transaction.
4. Compliance Before Acceptance
Technical receipt does not override KYC/AML requirements.
5. Transparent Allocation
The Participant must be able to understand how ARCBDS entitlement was calculated.
6. No Hidden Allocation Adjustments
Fees and deductions must be disclosed.
7. Accurate Records
Blockchain, finance and Participant records must be reconciled.
8. Secure Distribution
Wallet changes and high-value transactions require appropriate security.
9. Correct Errors Fairly
Manifest errors may be corrected in either direction.
10. Blockchain Reality + Contractual Reality
Blockchain records determine what occurred on-chain.
The Participation Agreement and Participation Confirmation determine the Participant's contractual entitlement.
Both must be reconciled accurately.
CONTACT
ARCBDS TRANSACTION SUPPORT
Official Website: www.arcbds.com
Legal Entity: [●]
Payment Support: [●]
Transaction Support: [●]
Compliance: [●]
Complaints: [●]
Never send ARCBDS, USDT, passwords, private keys or seed phrases to a person claiming to provide support through an unofficial channel.
FINAL TRANSACTION WARNING
Before transmitting digital assets:
CHECK THE ASSET.
CHECK THE NETWORK.
CHECK THE ADDRESS.
CHECK THE AMOUNT.
CHECK THE OFFICIAL DOMAIN.
Blockchain transactions may be permanent and irreversible.
A successful blockchain payment does not by itself mean that a Founding Circle application has been accepted.
Your official ARCBDS entitlement is established only after verification and issuance of the applicable Participation Confirmation.
END OF ARCBDS PAYMENT, ALLOCATION & BLOCKCHAIN TRANSACTION POLICY