Trust & Security 

At Agora AltX Our Commitment is Absolute

Commitment to Trust

Information Resources and Logistics are a principal asset of Agora AltX. They can provide a critical competitive advantage in the form of information gathering, information analysis, improved external communications, and increased customer responsiveness. As our Staff increasingly use Information Resources to connect with customers, service providers, and other key organizations, it is important that Staff understand and agree on the appropriate procedures to protect Company assets.

Agora AltX maintains a security policy which provides guidance and direction as a set of mechanisms by means of which Agora AltX’s information security objectives can be defined and attained. Agora AltX has established the following information security objectives:

  • Information confidentiality– ensures that only the people who are authorized to have access to information are able to do so. This policy ensures that only authorized staff have access to information.
  • Information integrity– maintains the value and the state of information so it is protected from unauthorized modification. This policy ensures that information is not modified or destroyed or subverted in any way.
  • Information availability– ensures that information and information systems are available and operational when they are needed. This policy ensures that information is always available to support critical business processing.

Application Security

After the third failed login, Agora AltX accounts are locked out for an exponentially increasing duration. The initial lock out is one minute and doubles after each subsequent failed login attempt up to a maximum lock out duration of one hour.

All login sessions require two factor authentication to prevent credential stuffing.

Client phone numbers and email addresses are provided prior to the onboarding process. During the onboarding process, the client is given the option to provide a phone number. If this phone number differs from the phone number provided during the onboarding initiation, the admin who initialized the onboarding event is sent an email notification informing them of the difference.

Whenever two factor authentication is successful on a device which the client has not previously used, an email notification containing geographic IP and device information is sent to the client with the option to terminate the session if the session has not been recognized. In this event, the client is forced to update their password.

Passwords have a minimum requirement of 12 characters. They must contain a combination of at least one uppercase letter, at least one lowercase letter, at least one number, and at least one of the following special characters: .*[!@#$%^&*].

Browser sessions are managed utilizing a JWT token. The JWT token is passed and authenticated with every request. If the JWT token is not valid, a 401 error is returned.

Authenticated JWT tokens are SHA256 signed to prevent cross site scripting. Once generated, JWT tokens are valid for a period of 48 hours.

Access control security is front end agnostic and exists as a “deny by default” software firewall layer above the application routes and is called before any route within the application is executed. All activity is denied unless the authenticated user is explicitly given access to.

Access privileges are considered “highly sensitive”. As such, permissions can only be granted or revoked by an authenticated admin using a secured (traffic filtered) instance. Permissions are evaluated by the logical role on a per-route basis (excepting the authentication route). Roles are attached to logical groups.  Authenticated entities are only granted the roles attached to the groups they belong to.

All groups are designed to contain the minimal permissions required to perform specified operations and to enforce a separation of duties between participants within all business operations of the Agora AltX app wherein a single authenticated session can not complete a transaction.

All data is AES encrypted at rest using an algorithmically derived encryption key not stored in memory so as to prevent capture from exploits known to abuse the hardware designs of RAM.

All SQL operations are performed with credentials having the minimum access rights to perform the operation. All SQL connection strings are AES encrypted objects stored within the application binary and are only decrypted as part of the SQL execution process.

All PostgreSQL instances have their public IP addresses detached from the instance interfaces and are only accessed via the VPC.


Encryption In Transit
All communication utilizing personally identifiable information of clients and authentication credentials are encrypted with strong encryption. Email transmissions are assumed to be insecure and such communication must not be conducted by way of email.

Encryption of data in transit may take any of the following forms:

  • Network encryption, in which data is encrypted at the IP layer (e.g. IPSec).
  • Session encryption, in which data is encrypted at a TCP layer (e.g.TLS).
  • Message encryption, in which blocks of data are encrypted before they are sent (e.g. S/MIME).
  • Data encryption, in which the entire data package is encrypted before it is transmitted (e.g. GPG)
  • Encryption systems used must offer strong encryption and use internationally recognized encryption algorithms. The choice of the crypto-algorithm is the responsibility of the CSA.

Encryption At Rest

All personal or entity identifiable is stored with strong encryption (e.g. AES-256) including contact information, account information and any information which could be used to interrelate persons, groups or entities.

Encryption of data at rest may take any of the following forms across all storage platforms including SQL, NoSQL, Graph DB and blockchain records:

  • Encrypted all sensitive text in all data types (including TEXT and JSON) objects at all storage levels
  • Encrypted unique identifiers where relationships are sensitive in nature
  • Encrypted unique identifiers where data overlaps storage technology stacks (e.g. SQL, NoSQL, Graph DB and blockchain records)
  • AES encrypted credentials utilizing AES encrypted MD5 password string hashes
  • Encrypted document storage including AWS S3 Buckets

Transaction specific information such as units, amounts and timestamps may be stored without encryption provided that there are no means to relate any transaction data to a person, group or entity directly or indirectly without use of decryption.

Blockchain: All records containing data classified above public must be encrypted using the Agora Altx binary encryption library. Records that exist on private channels are not exempt from this requirement.

Fraud Detection and Prevention

Internal controls are preventive, detective and corrective. Detective controls are used to identify potential acts of fraud throughout all Agora Altx activity. Preventive controls must be in place with the purpose of making acts of attempted fraud on the Agora Altx system inherently more costly than any potential gain that could be obtained through fraudulent activity. Active mitigation of losses or revisions to existing policy are classified as corrective controls.

Separation of Duties: As a matter of policy, all activity should be broken into steps to be conducted by multiple participants as appropriate to the separation of duties. (e.g. authorizing transactions, processing transactions, approving distributions etc.). Application security groups containing transaction inition roles cannot contain transaction authorization roles. Separation of these group types should be enforced system wide whenever possible.

ID Certainty: Reasonable certainty assessments can be derived for an activity by matching data provided by an authenticated user with data provided by a third party detection vendor.

Third party services (e.g. Blockscore) must be used for ID verification when any participant attempts to modify any contact information, executing any financial transactions or registering MFA devices (see Elevated Identity Verification Flagging). Third party ID verification records will be encrypted and stored to prevent subsequent events from triggering which may contain information that doesn’t match previous verification data.

Additionally, a series of prompts requiring the authenticated user to select an accurate vendor provided record against similar fabricated records. If an authenticated user’s selections do not match those on file with the used third party detection provider, this event is then flagged as potentially fraudulent (see mitigation).

Certainty of identity is the strongest when it has been verified by multiple participants with a relationship of at least ninety days to the entity in question.

The below logic serves to prioritize the verification process in descending order of priority. An elevated identity has been confirmed if at least two of the following verifications have been met (ordered in certainty from highest level to lowest):

  • Confirmation of identity and request details from another authorized signer
  • Confirmation of the identity of the individual making the request and the request details have both been confirmed by counter entity participant (e.g. fund, investor, etc) to the request
  • Correctly answered previously supplied security question
  • Confirmation has been made through an alternative contact method previously provided by the requesting participant

Data moving on the network between any two network-components is considered to be “data in transit”. This also includes all control and management sessions. All network technologies are regarded as either “safe” or “unsafe” in their native state (i.e. without any encryption).

All data in transit over an unsafe network segment that has a classification lower than the classification of the data must be protected by data encryption. Data in transit over a safe network segment may be encrypted at the discretion of the CSA.


A continuous infrastructure inventory is required and the Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) are monitored daily to ensure that any known vulnerabilities are patched as soon as possible.

Information System Communications

The CSA shall ensure that:

  • Processes are implemented to monitor, control, and protect Information Systems from information transmitted or received at the external boundaries and key internal boundaries of the Information Systems.
  • Information System designs, software development techniques, and systems engineering principles promote effective information security.
  • Information System management duties and functionality is separated from user functionality.
  • Controls are implemented and maintained to prevent unauthorized and unintended information transfer via shared system resources.
  • Publicly accessible subnetworks are physically or logically separated from internal networks.
  • Processes deny network communications traffic by default (i.e. deny all) and only allow network communications traffic by exception.
  • Security mechanisms prevent remote devices from simultaneously establishing non-remote connections with the Information System while also communicating via some other connection to external networks.
  • Cryptographic controls prevent unauthorized disclosure of data during transmission unless otherwise protected by alternative physical safeguards. Encryption is sufficient and effective and according to the classification of the data. Keys are properly managed and maintained.
  • Communications devices terminate network connections at the end of the sessions or after a defined period of inactivity.
  • Mechanisms prohibit the remote activation of collaborative computing devices. Appropriate notifications are provided to the user(s) of such devices.
  • Controls and monitoring systems are implemented on mobile code.
  • Security and monitoring systems are implemented on Voice over Internet Protocol (VoIP) systems.
  • Security systems protect the authenticity of communications sessions.
  • Security mechanisms protect the confidentiality of data during transmission and at rest.

To prevent a regional disaster from disrupting business services, critical infrastructure must be ready and available for on-demand deployment across multiple geographic regions.

Critical machine image and data volumes are synchronized across multiple AWS regions.

It is the responsibility of the CSA to oversee quarterly multi-region availability tests. These tests are used as benchmarks for improving service availability and ensuring minimal impact should a host region become unavailable.