General

Switch a module on or off#

The Modules row lists the modules your deployment offers this organisation, with a switch for each. It reads “Choose which of the modules your deployment offers this organisation uses. A module that is switched off stays viewable but cannot be changed.” When the deployment offers none, the row reads “Your deployment offers no modules.”

Turning a module off opens “Switch off <module>?” and says “<module> becomes read-only for your organisation. Nobody can change its records until an admin switches it on again.” The dialog first checks what is still open and lists it, or reads “Nothing is open in <module>.” when nothing is. It checks these kinds:

• “Open token sales”
• “Open dealing requests”
• “Running trading sessions”
• “Open multisig wallet drafts”
• “Withdrawals in progress”
• “Changes waiting for approval”

A kind it could not check reads “<kind>: could not check”. Select Switch off to confirm or “Keep on” to leave the module on. After a save the row reads “Modules saved”.

Choose the languages#

The “Language and time zone” section holds the Languages row and, below it, the “Display time zone” row. In the “Languages” row, an organisation owner chooses which of the ten languages people in the organisation can pick, and Languages covers that row.

Set the display time zone#

The investor portal shows every time, chart axis, statement date and deadline in the display time zone, with its short name, whatever time zone the investor's browser uses. An investor in Brussels and an investor in Dubai then read the same trade at the same clock time, and that time matches the instrument's own trading day. For Asia/Dubai the portal writes GST, short for Gulf Standard Time.

The Display time zone row shows the zone in use and where it comes from:

• Set for your organisation. An owner chose a zone from the searchable list. “Search time zones” filters it, and the list reads “No time zone matches.” when nothing fits.
• Follows the venue calendar. No zone is stored, and every trading venue calendar of the organisation uses the same zone.
• No venue calendar zone applies, so times show in UTC. No zone is stored, and the venue calendars set no zone or set different ones.

Choose Use the venue calendar zone to clear a stored zone. A save toasts “Display time zone saved”. The Console itself keeps showing UTC.

Publish trading terms and risk disclosures#

The “Terms and risk disclosures” row, in the “Terms and disclosures” section, publishes the documents that participants must accept before they can trade or withdraw. Choose “Terms” or “Risk disclosure”, enter a numeric version and either the document text or a file reference, then select Publish.

Set Require participants to accept this version again when an update should prompt every participant. Without it, an acceptance of an earlier version with the same major number still counts. The Console publishes a version that takes effect at once. Through the API, a future effective date keeps the version out of the gate until that date.

The row counts published versions and recorded acceptances. Export acceptances downloads the participant, document, version, time, and request metadata as CSV. The Investor portal shows the current effective versions after sign-in and opens the rest of the portal only after the participant accepts each one.

Show redemption funding to holders#

The “Terms and disclosures” section also holds the Redemption funding row. Its switch is named by the text beside it: “Hidden from holders” until you turn it on, and “Shown to holders” afterwards, so a screen reader announces the same words a sighted reader sees. It controls what a holder sees when they redeem a matured bond, and whether a refused yield claim names the yield treasury and the amount owed. A link on a bond's maturity tab opens this row.

• Off: the holder's redeem sheet shows no treasury figure and no shortfall notice. The role holders this section names still see the figures. If the treasury cannot pay, the redemption is refused with “This redemption cannot be completed”, and a yield claim the treasury cannot pay is refused with “The yield treasury cannot pay this claim yet”, without the treasury or the amount owed.
• On: the holder's redeem sheet, in the Console and in the investor portal, shows the treasury's available balance in the denomination asset. When the requested payout is more than that balance, the sheet shows the shortfall and blocks the redemption. A redemption or yield claim the treasury cannot pay is refused with an error that names the treasury and the amounts.

The redeem sheet reads the switch each time it opens. A change applies the next time a holder opens the sheet, with no page reload, and the sheet hides the treasury figure until that read settles.

An account that holds a management role on the asset always sees the treasury figures, whatever the switch says: custodian, emergency, funds manager, governance, sale admin or supply management. So does an account with the “Permission manager”, “Auditor”, “System manager” or “Token manager” role on the system, and the bond's maturity treasury wallet. Only an organisation owner can change the switch in the Console.

Set idle sign-out#

The “Security” section opens with the Idle sign-out row. It signs a person out after the chosen time without activity. In the Investor portal, that means no mouse, keyboard or page-visibility activity. Everywhere, it also means no request has reached the platform for that long. The choices are “Off”, 15 minutes, 30 minutes, 1 hour, 2 hours or 4 hours. “Off” is the default and keeps people signed in until their session ends. A choice saves at once and the row reads “Idle sign-out setting saved”. The row lists a stored value outside its choices as an extra choice.

Set the cooling-off period#

The “Security” section holds the Cooling-off after a wallet security change row, after “Idle sign-out”. These changes to a member's wallet signing factors count as a wallet security change:

• a transaction PIN set, changed, removed or reset
• a transaction code added or removed
• recovery codes regenerated

After one, DALP emails the member what changed, when and from where, and refuses every transaction that needs their wallet verification, the PIN, transaction code or recovery code that confirms a transaction, for the period this row sets. The row shows the period in hours when it divides evenly, “24 hours” by default, and “Off” at 0. A whole number of minutes from 0 to 10080, which is seven days, is accepted, and anything else reads “Enter a whole number from 0 to 10080.” Setting it to 0 turns the hold off. The security email is always sent. Select Save to store a new period, which toasts “Cooling-off period saved”.

The hold starts when a change alters or removes a factor the member already held, adds a second one, or replaces a confirmed set of recovery codes, and when an identity manager resets the member's PIN, so a new member who sets up their first PIN and recovery codes is not held. A member who sets a factor up again after an identity manager reset their PIN is held again from that setup.

While it stands, every signing request the member sends is refused with the instant the hold ends, in the Console and in the investor portal alike, and the same instant is in the email. A member of several organisations is held for the longest period any of them sets, so switching organisation never shortens the hold. A later security change restarts the period from that change.

Only an organisation owner can change the row in the Console. Anyone else who opens the page sees the value without a control.

Making the period longer saves at once. Making it shorter, or turning it off, weakens the hold for every member, so the Console opens Shorten the cooling-off period and asks for your wallet verification first. While you hold a transaction code, the platform accepts only that code and refuses a PIN or recovery code without saving. The save is refused while your own hold stands.

Members who are held at that moment are not a reason to refuse: their hold end is recomputed under the new period, and each of them whose hold end moves gets one email with the period that now applies to them and the new hold end, or that the hold has ended. A longer period can also bring back a hold that had already ended. That member gets the same email. No other member is emailed about the change.

An API key cannot shorten the period.

When a member's hold runs out, DALP emails them that their signing hold has ended, once per hold, within about five minutes. If the email cannot be sent, DALP tries again five minutes later. A hold that runs out on its own while the period is Off ends without this email.

Segregation of duties#

The Segregation of duties section sets which pairs of on-chain roles one wallet may not hold together, and what happens to a grant that would put a pair on one wallet. The “Check role grants” row holds the switch. It reads “Role grants are not checked” or “Role grants are checked against the rules”. The switch starts off, so no grant is compared with the rules until an owner turns it on. Roles already granted stay as they are, and the conflict report lists the pairs held today whether the switch is on or off.

Below the switch, a table lists the rules with the columns Roles, “Applies” and “When broken”. An organisation that never saved the setting sees the default pairs, each set to refuse the grant. The first change you save stores the whole rule set, so the defaults you leave in place stay in it.

• Applies reads “On the same contract” or “Anywhere in the organisation”. A same-contract rule breaks only when both roles sit on the same token, token sale or venue. An organisation-wide rule breaks wherever the wallet holds the two roles in the organisation's system.
• When broken reads “Refuse the grant” or “Ask for a reason”. A grant that breaks a refusing rule is turned away. A grant that breaks a rule that asks for a reason goes ahead only with a reason, which the audit trail keeps.

To change the rules, turn the switch on or off, choose another value in When broken on a row, or open a row's menu and choose “Remove rule”. To add a rule, go to “Add a rule” under the table, choose the “First role” and the “Second role”, set “Applies” and “When broken”, and choose “Add rule”. A pair takes one rule for each place it applies. “Choose two different roles.” and “This pair already has a rule in that scope.” tell you why a rule is not added. Each change saves at once and toasts “Segregation of duties saved”.

Only an owner can change the rules in the Console. Anyone else who opens the page sees the rules without a switch, a menu or Add a rule.

The Console's role editors send no reason. A grant that breaks a rule that asks for a reason is therefore turned away there, with the line “The organisation allows this grant with a reason. Send it through the Platform API.” The alert above the buttons names each pair that conflicts, such as “Custodian cannot be held with Governance on the same contract.” Roles and permissions shows where the editor shows it, and the Roles and segregation of duties reference lists the roles and the default pairs.

Approvals#

The Approvals section chooses which changes wait for a second person. It lists ten families: Offerings, Corporate actions, Trading venues, Reporting, Bank rail, Custody operations, Withdrawals, Prices, Wallets and Administration. Each row reads “Second person required” or “Not required” and has a “Turn on” or “Turn off” button. Its screen-reader label names the family, such as “Turn off approval for offerings”.

The Reporting row and its obligation exceptions read the same way, although the row also controls publishing an obligation, which never waits for a second person. The row's description says what waits while the family is on, or what goes ahead while it is off. A save toasts “Approval rule saved”.

The person who makes a change never approves it. A different person who may approve that kind of change decides it on the Actions page.

• Offerings: creating an offering, opening it for sale, ending it and running the allocation of an oversubscribed offering wait for a second person. The approver sees the sale terms before deciding: the token, the caps, the purchase limits, the start, the duration, the network, the payment currencies with their price per token, the country by name, the presale discount as a percentage and the terms fingerprint.

• Corporate actions: recording a corporate action waits for a second person.

• Trading venues, Reporting and Administration: the row sets the organisation-wide choice. A venue, a reporting obligation or an Administration protection group that has its own choice appears under “Exceptions”: a venue by its name and network, an obligation by its name, a group by its label. Each exception has its own “Turn on” or “Turn off” button and a “Remove” button that returns it to the family's choice.

  To add one, pick from the list under the row (“Choose a venue”, “Choose an obligation” or “Choose a protection group”), then select “Require approval for this one” when the family is off, or “Turn off approval for this one” when it is on.

  Until you pick, the button stays disabled and the row says why, for example “Choose a venue to add an exception.” The list offers the venues on the network the Console is set to, and the first 100 obligations.

• Reporting: while it is on, releasing a venue legal hold waits for a second person, and the platform publishes a reporting obligation only while the organisation has at least two members with the Owner role. Otherwise publishing is refused with DALP-0719. An obligation exception changes only that obligation's publishing check, with “Turn on the check for this one” and “Turn off the check for this one”.

• Bank rail: the row decides whether these changes wait for a different Bank rail manager: a cash-out over the checker threshold, a credit over the credit threshold, the allocation or return of a parked credit, a reserve adjustment, a raised or removed credit threshold or mint cap and the completion or abandoning of a rail wallet rotation.

  Three controls wait for a different manager whatever the row says: approving a client's bank account, executing or abandoning a recall, and the re-credit of a returned payout. The “Approvals required” count applies to the family's changes only. When it is above 1, only an organisation owner who also holds the Bank rail manager role can decide them.

  Bank rail lists the changes from the manager's side.

• Custody operations: resolving a reconciliation break waits for a second person. Custody reconciliation shows it from the reconciler's side.

• Withdrawals: the row remains but governs nothing. Withdrawal approvals are retired, so withdrawals go ahead without a second person.

• Prices: a held price from a price source waits for a second person before it is used. Price sources explains the hold.

• Wallets: the row decides whether pushing a wallet's entitlements waits for a second person. A wallet approval that names its checker always waits for that person, whatever the row says.

Under the state of each family that is on, except Reporting, Approvals required sets how many different people must approve before a change in the family goes ahead. It starts at 1 and goes up to 10. The person who made the change never counts.

The count you set here applies to every kind of change in the family, and a venue or protection group follows it. Through the API an owner can also give one kind of change its own count, approver roles and expiry, and give a venue or protection group its own count. The row then shows the highest count among the family's kinds. The Reporting row has no count, because nothing in Reporting would read one: one different person decides a legal hold release, and publishing an obligation needs two members with the Owner role. A change that is already waiting keeps the count it started under. Approver roles set on administrative changes never apply to a change of these approval rules: another owner or a platform administrator still approves that.

Raising the count saves at once. Lowering it weakens a control, so the Console opens “Ask for fewer approvals for <family>?” and asks for your wallet verification, as “Turn off” does. Select Lower the count to continue or “Keep the current count” to cancel. While any Administration protection group is protected, the lower count then waits for another owner or platform administrator to approve it. “Actions” shows a change that needs several approvers with its progress, for example 1 of 2. If you ask for more approvers than the organisation has people who may approve the change, it cannot be completed and lapses.

“Turn on” saves at once. Turn off weakens a control, so it opens “Turn off second-person approval for <family>?” and asks you to confirm with your wallet verification. “Turn off approval” sends the change and “Keep approval on” cancels it.

A similar confirmation, which also asks for your wallet verification, guards every other change that removes a second-person check: turning an exception off, adding an exception that turns approval off, and, while the family is off, removing an exception that required approval (“Remove the exception for <name>?”, with “Remove exception” and “Keep exception”). An obligation exception removes no second-person check, so its confirmation reads “Allow publishing <name> with fewer than two owners?” instead, with “Allow publishing” and “Keep the check”. The change then applies at once.

While any Administration protection group is protected, the change waits for approval instead: the row keeps its current state and reads “Turn-off waiting for approval” until another owner or a platform administrator decides. That approver can be a platform administrator, so no owner of the organisation is necessarily asked.

The row says who asked, when, and when the request lapses, in UTC: it names the member who asked, or reads “someone else” when the name is not known. On a turn-off you asked for yourself, the row offers Withdraw request in place of “Turn off”. It cancels the request at once, with no PIN: the family keeps asking for approval, and the request leaves Actions so nobody can approve it.

Only the member who asked can withdraw it. Another owner approves or rejects it instead. A request already waiting keeps the rule it started under.

A request raised while its family is off runs without a second person. Actions and its detail sheet show it as “No second approval (approval off)”. While any Administration protection group is protected, every edit of the list of protection groups and every change that switches a family or exception off or lowers a count waits for an owner or platform administrator to approve it, whatever the number of owners. Turning a family on and raising a count apply at once, with no PIN. A session in which a platform administrator acts as another user cannot switch an approval off, lower a count or remove an exception. Sign in as yourself to do it.

Troubleshooting#

Frequently asked questions#

API routes#

• The IDLE_TIMEOUT_MINUTES setting behind Idle sign-out is written through POST /api/v2/settings, which accepts off or a whole number of minutes from 5 to 240.
• The SIGNING_FACTOR_COOLDOWN_MINUTES setting behind the cooling-off row is written through POST /api/v2/settings. A value below the current one needs walletVerification in the body. Deleting the setting, which returns it to the default, is refused while the current period is longer than the default. Set it to 1440 with walletVerification instead. Both checks run again against the value stored at the moment of the write, so a save that another administrator's longer period, saved just before it, turns into a shortening is refused with 403. Verify and save again. A held signing request answers 403 WALLET_VERIFICATION_HELD with heldUntil and retryAfterSeconds in its data.
• The approval rules are GET /api/v2/operations/approval-policy and PUT /api/v2/operations/approval-policy, where each family carries requiredApprovals and, under kinds, each kind of change its own enabled, requiredApprovals, approverRoles and expiryHours. A PUT with kind sets only that kind. A PUT that weakens a rule needs walletVerification: turning a kind off, lowering its count, adding an approver role, making its expiry longer, or setting roles or an expiry where the kind used the action's own. A PUT that is held answers 202 with the approval id. The setting CORPORATE_ACTION_MAKER_CHECKER_ENABLED reads and writes the Corporate actions row.
• The display time zone is readable with GET /api/v2/settings/display-time-zone, which answers the zone and its source.
• The redemption funding switch controls the v2 reads GET /api/v2/tokens/{assetId}/stats?metric=bondStatus and GET /api/v2/tokens/{assetId}/treasury/health. While it is off, any other caller gets a 403 TREASURY_DISCLOSURE_WITHHELD answer from both. The frozen v1 read GET /v1/token/{tokenAddress}/stats/bond-status is outside the switch: any member of the organisation can still read it.